FreeBSD Quarterly Status Report - Second Quarter 2016

2016-07-27 Thread Benjamin Kaduk 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

FreeBSD Project Quarterly Status Report - Second Quarter 2016

   Now available: the 2016Q2 model of the FreeBSD Project Status Report!

   This quarter brings several exciting improvements over previous models.
   We have enhancements from different teams, new features like robust
   mutexes and support for full disk encryption with GELI. You'll find
   expanded graphics support, both at the chipset and window manager
   levels, and ongoing development in many pending features.

   Perhaps most exciting, under the hood you'll find a brand-new Core
   Team.

   Don't wait. Take FreeBSD for a spin today.

   --Michael W. Lucas
 __

   Please submit status reports for the third quarter of 2016 by October 7.
 __

FreeBSD Team Reports

 * FreeBSD IRC Admin Team
 * FreeBSD Issue Triage Team
 * FreeBSD Release Engineering Team
 * Ports Collection
 * The FreeBSD Core Team
 * The FreeBSD Foundation

Projects

 * ASLR Interim State
 * Ceph on FreeBSD
 * EFI Refactoring and GELI Support
 * Robust Mutexes
 * The Graphics Stack on FreeBSD

Kernel

 * ARM Allwinner SoC Support
 * FreeBSD on Hyper-V and Azure
 * VIMAGE Virtualized Network Stack Update

Architectures

 * FreeBSD/arm64

Userland Programs

 * Reproducible Builds in FreeBSD
 * Updates to GDB
 * Using lld, the LLVM Linker, to Link FreeBSD

Ports

 * Bringing GitLab into the Ports Collection
 * GNOME on FreeBSD
 * Intel Networking Tools
 * IPv6 Promotion Campaign
 * KDE on FreeBSD
 * Obsoleting Rails 3
 __

FreeBSD Team Reports

FreeBSD IRC Admin Team

   Links
   FreeBSD IRC Wiki
URL: https://wiki.FreeBSD.org/IRC/

   Contact: IRC Admin Team 

   Contact: Kubilay Kocak 

   Contact: Eitan Adler 

   The FreeBSD IRC Admin team manages the FreeBSD Project's IRC presence
   on the freenode IRC network, looking after:
 * Registrations and ongoing management of channels within the
   official namespace (#freebsd*).
 * Liaising with freenode staff.
 * Allocating freebsd hostmask cloaks for users.
 * General user support.

   In order to facilitate a constructive and positive environment for all
   members of the FreeBSD community, IRC Admin over the past 3-9 months
   has established and consolidated a consistent baseline with respect to
   the management of its channels on freenode. This report is a summary of
   what has happened so far and things to come.

   These activities were completed over the last few quarters:
 * Registered FreeBSD Group Contacts (GC) with freenode staff. For
   information on what this means, see the group registration page.
 * Created a FreeBSD NickServ account to assign as primary
   owner/founder of the #freebsd* namespace channels.
 * The primary channels are owned/founded by a generic FreeBSD account
   that is owned and managed by the FreeBSD Project.
 * Created the Services::IRC component in Bugzilla for change requests
   and issue reports.
 * Obtained a report of all registered freenode channels matching the
   #freebsd* namespace and assessed the list for current ownership and
   activity status.
 * Assigned freebsd/ user cloaks to users requesting them. For more
   information, see IRC Cloaks.
 * Obtained a report on all nicknames and accounts with existing
   freebsd/* user cloaks.
 * Liaised with freenode staff on upcoming changes to freebsd
   channels.

   The goals for the next few quarters are to:
 * Complete the transfer of founder ownership for all #freebsd*
   channels. Existing channel creators, some of whom are project
   members and others who are not, will be contacted using known
   contact information or contact information set in their registered
   NickServ account, in order to initiate the transfer of the channel
   to the FreeBSD Project. If the contact information of the existing
   channel owner cannot be obtained, or if no response is received
   after a suitable period of time has elapsed, IRC Admin will
   complete the ownership transfer with freenode staff.
 * Deregister defunct and inactive #freebsd* channels. Channels which
   have no visible signs of activity based on last active time or
   registered owner last seen, have been deprecated by alternative
   channels, or have no other way of having ownership transferred will
   be deregistered. For channels where a sunset period may be
   suitable, a channel topic will be set, and optionally a forwarding
   channel, informing users of the changes, including support and
   contact information.

IWM(7260), no connect

2016-07-27 Thread Larry Rosenman 
I'm running today's top of tree, and it doesn't seem to want to connect:


re0: flags=8843 metric 0 mtu 1500

options=8209b
ether 20:47:47:73:07:5f
inet6 fe80::2247:47ff:fe73:75f%re0 prefixlen 64 scopeid 0x1 
inet6 2001:470:1f0f:42c:2247:47ff:fe73:75f prefixlen 64 autoconf 
inet 192.168.200.246 netmask 0xfc00 broadcast 192.168.203.255 
nd6 options=23
media: Ethernet autoselect (1000baseT )
status: active
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
inet 127.0.0.1 netmask 0xff00 
nd6 options=21
groups: lo 
wlan0: flags=8c43 metric 0 mtu 
1500
ether 58:91:cf:1a:45:69
inet6 fe80::5a91:cfff:fe1a:4569%wlan0 prefixlen 64 scopeid 0x3 
nd6 options=23
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
ssid "" channel 8 (2447 MHz 11g)
regdomain FCC country US authmode WPA1+WPA2/802.11i privacy ON
deftxkey UNDEF txpower 30 bmiss 10 scanvalid 60 protmode CTS wme
roaming MANUAL
groups: wlan 


hostb0@pci0:0:0:0:  class=0x06 card=0x07061028 chip=0x19108086 rev=0x07 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Skylake Host Bridge/DRAM Registers'
class  = bridge
subclass   = HOST-PCI
pcib1@pci0:0:1:0:   class=0x060400 card=0x20158086 chip=0x19018086 rev=0x07 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Skylake PCIe Controller (x16)'
class  = bridge
subclass   = PCI-PCI
pcib2@pci0:0:1:1:   class=0x060400 card=0x07061028 chip=0x19058086 rev=0x07 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Skylake PCIe Controller (x8)'
class  = bridge
subclass   = PCI-PCI
vgapci1@pci0:0:2:0: class=0x03 card=0x07061028 chip=0x191b8086 rev=0x06 
hdr=0x00
vendor = 'Intel Corporation'
device = 'HD Graphics 530'
class  = display
subclass   = VGA
none0@pci0:0:4:0:   class=0x118000 card=0x07061028 chip=0x19038086 rev=0x07 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Skylake Processor Thermal Subsystem'
class  = dasp
xhci0@pci0:0:20:0:  class=0x0c0330 card=0x07061028 chip=0xa12f8086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H USB 3.0 xHCI Controller'
class  = serial bus
subclass   = USB
none1@pci0:0:20:2:  class=0x118000 card=0x07061028 chip=0xa1318086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Thermal subsystem'
class  = dasp
none2@pci0:0:21:0:  class=0x118000 card=0x07061028 chip=0xa1608086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Serial IO I2C Controller'
class  = dasp
none3@pci0:0:22:0:  class=0x078000 card=0x07061028 chip=0xa13a8086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H CSME HECI'
class  = simple comms
ahci0@pci0:0:23:0:  class=0x010601 card=0x07061028 chip=0xa1038086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H SATA Controller [AHCI mode]'
class  = mass storage
subclass   = SATA
pcib3@pci0:0:28:0:  class=0x060400 card=0x07061028 chip=0xa1108086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib4@pci0:0:28:4:  class=0x060400 card=0x07061028 chip=0xa1148086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib5@pci0:0:28:5:  class=0x060400 card=0x07061028 chip=0xa1158086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib6@pci0:0:28:6:  class=0x060400 card=0x07061028 chip=0xa1168086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
isab0@pci0:0:31:0:  class=0x060100 card=0x07061028 chip=0xa14e8086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H LPC Controller'
class  = bridge
subclass   = PCI-ISA
none4@pci0:0:31:2:  class=0x058000 card=0x07061028 chip=0xa1218086 rev=0x31 
hdr=0x00
vendor = 'Intel

Re: Boot environments and zfs canmount=noauto

2016-07-27 Thread Allan Jude 
On 2016-07-27 22:05, Randy Westlund wrote:
> I'm trying to follow Michael Dexter's post about using bhyve with boot
> environments.  It involves moving all child datasets under
> zroot/ROOT/default, so that you can have entirely independent systems.
> 
> http://callfortesting.org/bhyve-boot-environments/
> 
>> Let's change the datasets with "canmount on" to "canmount noauto":
>> [snip]
>> Considering that this setting is harmless to a system with a single
>> boot environment, I would not object to it being the default. Hint
>> hint. 
> 
> When I set all the datasets with canmount=on to canmount=noauto, only
> zroot/ROOT/default gets mounted on next boot.  It's my understanding
> that 'zfs mount -a' doesn't mount datasets with canmount=noauto, but if
> I leave them with canmount=on, they will try to mount regardless of
> which BE is active.
> 
> I'm trying this with 11.0-BETA2.  Can sometime tell me what I'm missing?
> 

You are not missing anything. This is why the default is to have all
files that are specific to a BE be in the root dataset, and only files
that are global (like home directory, etc) be outside of the BE.

In order to do it the way Dexter is proposing, you can set them
canmount=noauto or with mountpoint=legacy, and then mount them via fstab
(defined differently in each BE), but that kind of defeats a lot of the
purpose of ZFS.


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Boot environments and zfs canmount=noauto

2016-07-27 Thread Randy Westlund 
I'm trying to follow Michael Dexter's post about using bhyve with boot
environments.  It involves moving all child datasets under
zroot/ROOT/default, so that you can have entirely independent systems.

http://callfortesting.org/bhyve-boot-environments/

> Let's change the datasets with "canmount on" to "canmount noauto":
> [snip]
> Considering that this setting is harmless to a system with a single
> boot environment, I would not object to it being the default. Hint
> hint. 

When I set all the datasets with canmount=on to canmount=noauto, only
zroot/ROOT/default gets mounted on next boot.  It's my understanding
that 'zfs mount -a' doesn't mount datasets with canmount=noauto, but if
I leave them with canmount=on, they will try to mount regardless of
which BE is active.

I'm trying this with 11.0-BETA2.  Can sometime tell me what I'm missing?


signature.asc
Description: PGP signature

FreeBSD_HEAD_i386 - Build #3702 - Fixed

2016-07-27 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #3702 - Fixed:

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

Change summaries:

303419 by bdrewery:
Fix non-amd64 build from r292043 after reconnecting in r303410.

MFC after:  3 days
X-MFC-With: r303410
Sponsored by:   EMC / Isilon Storage Division

___
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: SafeStack in base

2016-07-27 Thread Conrad Meyer 
On Wed, Jul 27, 2016 at 5:05 PM, Shawn Webb  wrote:
> On Wed, Jul 27, 2016 at 05:02:07PM -0700, Conrad Meyer wrote:
>> The problem appears to be an upstream limitation of
>> -fsanitize=safe-stack: "Most programs, static libraries, or individual
>> files can be compiled with SafeStack as is. ??? Linking a DSO with
>> SafeStack is not currently supported." [0]
>>
>> That probably needs to be addressed upstream before it can be enabled 
>> globally.
>
> Gotcha. If I'm reading correctly, then, SafeStack can only be enabled in
> bsd.prog.mk (and _not_ bsd.lib.mk). Is that correct?

That is my reading of the page.  I'll admit my total experience with
-fsanitize=safe-stack is limited to glancing at the web page 5 minutes
ago, so don't consider my take authoritative.

Best,
Conrad
___
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: SafeStack in base

2016-07-27 Thread Shawn Webb 
On Wed, Jul 27, 2016 at 05:11:12PM -0700, Conrad Meyer wrote:
> On Wed, Jul 27, 2016 at 5:05 PM, Shawn Webb  
> wrote:
> > On Wed, Jul 27, 2016 at 05:02:07PM -0700, Conrad Meyer wrote:
> >> The problem appears to be an upstream limitation of
> >> -fsanitize=safe-stack: "Most programs, static libraries, or individual
> >> files can be compiled with SafeStack as is. ??? Linking a DSO with
> >> SafeStack is not currently supported." [0]
> >>
> >> That probably needs to be addressed upstream before it can be enabled 
> >> globally.
> >
> > Gotcha. If I'm reading correctly, then, SafeStack can only be enabled in
> > bsd.prog.mk (and _not_ bsd.lib.mk). Is that correct?
> 
> That is my reading of the page.  I'll admit my total experience with
> -fsanitize=safe-stack is limited to glancing at the web page 5 minutes
> ago, so don't consider my take authoritative.

Doing a test build right now with SafeStack enabled only in bsd.prog.mk.
I'll report back with results tonight or tomorrow.

Thanks again,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: SafeStack in base

2016-07-27 Thread Shawn Webb 
On Wed, Jul 27, 2016 at 05:02:07PM -0700, Conrad Meyer wrote:
> On Wed, Jul 27, 2016 at 3:55 PM, Shawn Webb  
> wrote:
> > Hey All,
> >
> > I'm interested in getting SafeStack working in FreeBSD base. Below is a
> > link to a simplistic (maybe too simplistic?) patch to enable SafeStack.
> > The patch applies against HardenedBSD's hardened/current/master branch.
> > Given how simple the patch is, it'd be extremely easy to port over to
> > FreeBSD (just line numbers would change).
> >
> > I am running into a bit of a problem, though. When linking
> > lib/libcom_err, I get the following error:
> >
> > com_err.So: In function `com_err':
> > /usr/src/lib/libcom_err/../../contrib/com_err/com_err.c:100: undefined 
> > reference to `__safestack_unsafe_stack_ptr'
> > cc: error: linker command failed with exit code 1 (use -v to see invocation)
> > *** [libcom_err.so.5.full] Error code 1
> >
> > llvm's documentation says that SafeStack has been tested on FreeBSD.
> > When and how was it tested? Apparently someone has done some work to
> > enable it on FreeBSD, but I can't find any relevant FreeBSD-specific
> > documentation.
> >
> > If someone could point me in the right direction, I'd love to help get
> > SafeStack working (and commited?) in FreeBSD.
> >
> > Link to simplistic patch: http://ix.io/186A
> > Link to build log: 
> > https://gist.github.com/lattera/5d94f44a5f3e10a28425cd59104dd169
> 
> Hey Shawn,
> 
> The relevant link line is:
> 
> > -- libcom_err.so.5.full ---
> > building shared library libcom_err.so.5
> > cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
> > -B/usr/obj/usr/src/tmp/usr/bin -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now 
> > -fsanitize=safe-stack 
> > -Wl,--version-script=/usr/src/lib/libcom_err/../../contrib/com_err/version-script.map
> >  -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings 
> > -Wl,--warn-shared-textrel  -o libcom_err.so.5.full 
> > -Wl,-soname,libcom_err.so.5  `NM='nm' NMFLAGS='' lorder com_err.So error.So 
> > | tsort -q`
> 
> The problem appears to be an upstream limitation of
> -fsanitize=safe-stack: "Most programs, static libraries, or individual
> files can be compiled with SafeStack as is. ??? Linking a DSO with
> SafeStack is not currently supported." [0]
> 
> That probably needs to be addressed upstream before it can be enabled 
> globally.

Gotcha. If I'm reading correctly, then, SafeStack can only be enabled in
bsd.prog.mk (and _not_ bsd.lib.mk). Is that correct?

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: Possible race condition building libraries: head/amd64 r303329 -> r303379

2016-07-27 Thread Bryan Drewery 
On 7/27/2016 4:55 PM, David Wolfskill wrote:
> On Wed, Jul 27, 2016 at 04:34:39PM -0700, Bryan Drewery wrote:
>> ...
>> These shouldn't happen since libgcc is build in startup_libs and krb5 is
>> built in prebuild_libs, which waits on startup_libs. Very strange.
>>
>> Can you send me the typescript please?
>> 
> 
> (For folks playing along at home, I sent Bryan the typescript. I've also
> placed a copy at
> http://www.catwhisker.org/~david/FreeBSD/head/typescript_r303379.gz.)
> 

Yeah, very strange.

> 20609 Building /common/S4/obj/usr/src/gnu/lib/libgcc/libgcc_s.so.1^M  
> 20610 --- libgcc_s.so.1 ---^M 
> 20611 building shared library libgcc_s.so.1^M 
> 20612 Building /common/S4/obj/usr/src/gnu/lib/libgcc/_lib-eh-install^M
> 20613 Building /common/S4/obj/usr/src/gnu/lib/libgcc/_libinstall^M

It built libgcc_s, installed it to WORLDTMP...

> 25131 Building 
> /common/S4/obj/usr/src/kerberos5/lib/libwind/normalize_table.So^M
> 25132 --- kerberos5/lib/libheimipcc__L ---^M
> 25133 /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s^M
> 25134 cc: error: linker command failed with exit code 1 (use -v to see 
> invocation)^M
> 25135 *** [libprivateheimipcc.so.11] Error code 1^M
> 25136 ^M
> 25137 bmake[4]: stopped in /usr/src/kerberos5/lib/libheimipcc^M

Then failed to find it.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: SafeStack in base

2016-07-27 Thread Conrad Meyer 
On Wed, Jul 27, 2016 at 3:55 PM, Shawn Webb  wrote:
> Hey All,
>
> I'm interested in getting SafeStack working in FreeBSD base. Below is a
> link to a simplistic (maybe too simplistic?) patch to enable SafeStack.
> The patch applies against HardenedBSD's hardened/current/master branch.
> Given how simple the patch is, it'd be extremely easy to port over to
> FreeBSD (just line numbers would change).
>
> I am running into a bit of a problem, though. When linking
> lib/libcom_err, I get the following error:
>
> com_err.So: In function `com_err':
> /usr/src/lib/libcom_err/../../contrib/com_err/com_err.c:100: undefined 
> reference to `__safestack_unsafe_stack_ptr'
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [libcom_err.so.5.full] Error code 1
>
> llvm's documentation says that SafeStack has been tested on FreeBSD.
> When and how was it tested? Apparently someone has done some work to
> enable it on FreeBSD, but I can't find any relevant FreeBSD-specific
> documentation.
>
> If someone could point me in the right direction, I'd love to help get
> SafeStack working (and commited?) in FreeBSD.
>
> Link to simplistic patch: http://ix.io/186A
> Link to build log: 
> https://gist.github.com/lattera/5d94f44a5f3e10a28425cd59104dd169

Hey Shawn,

The relevant link line is:

> -- libcom_err.so.5.full ---
> building shared library libcom_err.so.5
> cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
> -B/usr/obj/usr/src/tmp/usr/bin -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now 
> -fsanitize=safe-stack 
> -Wl,--version-script=/usr/src/lib/libcom_err/../../contrib/com_err/version-script.map
>  -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings 
> -Wl,--warn-shared-textrel  -o libcom_err.so.5.full 
> -Wl,-soname,libcom_err.so.5  `NM='nm' NMFLAGS='' lorder com_err.So error.So | 
> tsort -q`

The problem appears to be an upstream limitation of
-fsanitize=safe-stack: "Most programs, static libraries, or individual
files can be compiled with SafeStack as is. … Linking a DSO with
SafeStack is not currently supported." [0]

That probably needs to be addressed upstream before it can be enabled globally.

Best,
Conrad

[0]: http://clang.llvm.org/docs/SafeStack.html
___
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: Possible race condition building libraries: head/amd64 r303329 -> r303379

2016-07-27 Thread David Wolfskill 
On Wed, Jul 27, 2016 at 04:34:39PM -0700, Bryan Drewery wrote:
> ...
> These shouldn't happen since libgcc is build in startup_libs and krb5 is
> built in prebuild_libs, which waits on startup_libs. Very strange.
> 
> Can you send me the typescript please?
> 

(For folks playing along at home, I sent Bryan the typescript. I've also
placed a copy at
http://www.catwhisker.org/~david/FreeBSD/head/typescript_r303379.gz.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Possible race condition building libraries: head/amd64 r303329 -> r303379

2016-07-27 Thread Bryan Drewery 
On 7/27/2016 5:49 AM, David Wolfskill wrote:
> I track head daily on both my laptop and a "build machine;" I only saw a
> problem on the latter -- not on my laptop.
> 
> (The build machine is a bit beefier, and uses an SSD as its non-volatile
> storage; the laptop uses a hybrid disk -- in case that is useful.)
> 
> As indicated in the Subject, in each case I was performing a
> source-based upgrade-in-place from r303329 to r303379.  (And I've
> been doing this routinely for quite some time.)
> 
> The build failed (initially -- a restart worked):
> 
> ...
 stage 4.2: building libraries
> ...
> --- secure/lib/libcrypto__L ---
> Building /common/S4/obj/usr/src/secure/lib/libcrypto/dso_openssl.o
> --- lib/ncurses/ncursesw__L ---
> /usr/lib/libtermlibw.so -> libncursesw.so
> /usr/lib/libtinfow.so -> libncursesw.so
> --- kerberos5/lib/libwind__L ---
> Building /common/S4/obj/usr/src/kerberos5/lib/libwind/normalize_table.So
> --- kerberos5/lib/libheimipcc__L ---
> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [libprivateheimipcc.so.11] Error code 1

Nathan Whitehorn ran into a very similar one last year that I couldn't
explain either.

> --- kerberos5/lib__L ---
> --- libkadm5srv.so.11 ---
> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc
> *** [libkadm5srv.so.11] Error code 1
> 
> make[5]: stopped in /usr/src/kerberos5/lib/libkadm5srv 


These shouldn't happen since libgcc is build in startup_libs and krb5 is
built in prebuild_libs, which waits on startup_libs. Very strange.

Can you send me the typescript please?

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

SafeStack in base

2016-07-27 Thread Shawn Webb 
Hey All,

I'm interested in getting SafeStack working in FreeBSD base. Below is a
link to a simplistic (maybe too simplistic?) patch to enable SafeStack.
The patch applies against HardenedBSD's hardened/current/master branch.
Given how simple the patch is, it'd be extremely easy to port over to
FreeBSD (just line numbers would change).

I am running into a bit of a problem, though. When linking
lib/libcom_err, I get the following error:

com_err.So: In function `com_err':
/usr/src/lib/libcom_err/../../contrib/com_err/com_err.c:100: undefined 
reference to `__safestack_unsafe_stack_ptr'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [libcom_err.so.5.full] Error code 1

llvm's documentation says that SafeStack has been tested on FreeBSD.
When and how was it tested? Apparently someone has done some work to
enable it on FreeBSD, but I can't find any relevant FreeBSD-specific
documentation.

If someone could point me in the right direction, I'd love to help get
SafeStack working (and commited?) in FreeBSD.

Link to simplistic patch: http://ix.io/186A
Link to build log: 
https://gist.github.com/lattera/5d94f44a5f3e10a28425cd59104dd169

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: EARLY_AP_STARTUP hangs during boot

2016-07-27 Thread Gary Jennejohn 
On Wed, 27 Jul 2016 14:43:36 -0700
John Baldwin  wrote:

> On Tuesday, June 07, 2016 12:06:54 PM Gary Jennejohn wrote:
> > On Tue, 31 May 2016 13:10:06 -0700
> > John Baldwin  wrote:
> >   
> > > On Saturday, May 28, 2016 02:11:41 PM Gary Jennejohn wrote:  
> > > > On Fri, 27 May 2016 09:50:05 +0200
> > > > Gary Jennejohn  wrote:
> > > > 
> > > > > On Thu, 26 May 2016 16:54:35 -0700
> > > > > John Baldwin  wrote:
> > > > > 
> > > > > > On Tuesday, May 17, 2016 06:47:41 PM Gary Jennejohn wrote:  
> > > > > > > On Mon, 16 May 2016 10:54:19 -0700
> > > > > > > John Baldwin  wrote:
> > > > > > > 
> > > > > > > > On Monday, May 16, 2016 12:22:42 PM Gary Jennejohn wrote:   
> > > > > > > >  
> > > > > > > > > I tried out EARLY_AP_STARTUP, but the kernel hangs and I can't
> > > > > > > > > break into DDB.
> > > > > > > > > 
> > > > > > > > > I did a verbose boot and the last lines I see are related to 
> > > > > > > > > routing
> > > > > > > > > MSI-X to various local APIC vectors.  I copied the last few 
> > > > > > > > > lines and
> > > > > > > > > they look like this:
> > > > > > > > > 
> > > > > > > > > msi: routing MSI-X IRQ 256 to local APIC 2 vector 48
> > > > > > > > > msi: routing MSI-X IRQ 257 to local APIC 3 vector 48
> > > > > > > > > msi: routing MSI-X IRQ 258 to local APIC 4 vector 48
> > > > > > > > > msi: routing MSI-X IRQ 256 to local APIC 0 vector 49
> > > > > > >  ^^^ Assigning
> > > > > > > > > 
> > > > > > > > > I tried disabling msi and msix in /boot/loader.conf, but the 
> > > > > > > > > settings
> > > > > > > > > were ignored (probabaly too early).  
> > > > > > > > 
> > > > > > > > No, those settings are not too early.  However, the routing to 
> > > > > > > > different
> > > > > > > > CPUs now happens earlier than it used to.  What is the line 
> > > > > > > > before the
> > > > > > > > MSI lines?  You can take a picture with your phone/camera if 
> > > > > > > > that's simplest.
> > > > > > > > 
> > > > > > > 
> > > > > > > Here a few lines before the MSI routing happens:
> > > > > > > 
> > > > > > > hpet0:  iomem 0xfed0-0xfed003ff 
> > > > > > > irq 0,8 on acpi0
> > > > > > > hpet0: vendor 0x4353, rev 0x1, 14318180 Hz, 3 timers, legacy route
> > > > > > > hpet0: t0 : irqs 0x00c0ff (0), MSI, periodic
> > > > > > > hpet0: t1 : irqs 0x00c0ff (0), MSI, periodic
> > > > > > > hpet0: t2 : irqs 0x00c0ff (0), MSI, periodic
> > > > > > > Timecounter "HPET" frequency 14318180 Hz quality 950
> > > > > > 
> > > > > > The assigning message means it is in the loop using
> > > > > > bus_bind_intr() to setup per-CPU timers.  Can you please try
> > > > > > setting 'hint.hpet.0.per_cpu=0' at the loader prompt to see if
> > > > > > disabling the use of per-CPU timers allows you to boot?
> > > > > >   
> > > > > 
> > > > > Something has changed since the last time I generated a kernel with
> > > > > this option.
> > > > > 
> > > > > Now I get a NULL-pointer dereference in the kernel, doesn't matter
> > > > > whether I set the hint or not.
> > > > > 
> > > > 
> > > > OK, now that the startup has been fixed, I tried setting the hint at
> > > > the loader prompt, but the kenel hangs in exactly the same place as
> > > > before.  I actually booted twice to make certain I hadn't made a
> > > > typo when setting the hint.
> > > 
> > > Humm, it shouldn't be calling bus_bind_intr() if the hint is set.  
> > > Actually,
> > > I guess it just binds them all to first CPU if per-CPU timers aren't set.
> > > Can you add debug printfs to hpet_attach() in sys/dev/acpica/acpi_hpet.c 
> > > to
> > > narrow down which line in that function it hangs after?
> > > 
> > > Another option to try is to add the following to your kernel config:
> > > 
> > > options   KTR
> > > options   KTR_COMPILE=KTR_PROC
> > > options   KTR_MASK=KTR_PROC
> > > options   KTR_VERBOSE=1
> > > 
> > > this will spew a lot of crap to the screen, but if it stops spewing when 
> > > it
> > > hangs then it might be tell us where the system is hung.  If you have any 
> > > way
> > > to configure a serial console then this would also be useful even if it 
> > > spews
> > > constantly when it is hung (assuming you could log the output of the 
> > > serial
> > > console).
> > >   
> > 
> > I used the KTR options.
> > 
> > After the Timecounter "HPET" frequency 14318180 Hz quality 950 I see
> > 
> > cpu0 mi_switch: old thread 1 (swapper)
> > cpu0 mi_switch: new thread 10022 (if_config_tqg_0)
> > cpu0 sleep_broadcast(0x80002f9a600, 0)
> > cpu0 msleep_spin: old thread 100022
> > cpu0 mi_switch: old thread 10022
> > cpu0 mi_switch: new thread 10016 (if_io_tqg_0)
> > cpu0 sleep_broadcast(0x80002f9a780, 0)
> > cpu0 msleep_spin: old thread 10016
> > cpu0 mi_switch: old thread 10016
> > cpu0 fork_exit: new thread 0x80004239510 (td_sched 0x842399d8, pid
> > 10, idle:

FreeBSD_HEAD_i386 - Build #3701 - Failure

2016-07-27 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #3701 - Failure:

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

Change summaries:

303418 by ivadasz:
[iwm] When stopping TX DMA, wait for all channels at once.

* Makes the TX DMA stopping more similar to Linux code, and potentially
  a bit faster. Also, output an error message when TX DMA idling fails.

Taken-From: Linux iwlwifi

Tested:

* AC3165, STA mode

Approved by:adrian (mentor)
Obtained from:  DragonFlyBSD git 2ee486ddff973ac552ff787c17e8d83e8ae0f24c
Differential Revision:  https://reviews.freebsd.org/D7325

303417 by bdrewery:
opt_bdg.h was removed in r150636.

MFC after:  3 days
Sponsored by:   EMC / Isilon Storage Division

303416 by ivadasz:
[iwm] Set different pm_timeout for action frames.

When building a Tx Command for management frames, we are lacking
a check for action frames, for which we should set a different
pm_timeout.  This cause the fw to stay awake for 100TU after each
such frame is transmitted, resulting an excessive power consumption.

Taken-From: Linux iwlwifi (git b084a35663c3f1f7)

Approved by:adrian (mentor)
Obtained from:  Linux git b084a35663c3f1f7de1c45c4ae3006864c940fe7
Obtained from:  DragonFlyBSD git ba00f0e3ae873d6f0d5743e22c3ebc49c44dfdac
Differential Revision:  https://reviews.freebsd.org/D7324

303415 by bdrewery:
opt_apic.h is only used on i386.

MFC after:  3 days
Sponsored by:   EMC / Isilon Storage Division

303414 by bdrewery:
opt_random.h was removed in r287558 for opt_global.h

MFC after:  3 days
Sponsored by:   EMC / Isilon Storage Division

303413 by ivadasz:
[iwm] Fix inverted logic in iwm_tx().

The PROT_REQUIRE flag in should be set for data frames above a certain
length, but we were setting it for !data frames above a certain length,
which makes no sense at all.

Taken-From: OpenBSD, Linux iwlwifi

Approved by:adrian (mentor)
Obtained from:  DragonFlyBSD git 8cc03924a36c572c2908e659e624f44636dc2b33
Differential Revision:  https://reviews.freebsd.org/D7323

303412 by rrs:
Remove myself from kern_timeout.c yeah!

303411 by stevek:
Prepare for network stack as a module

 - Move cr_canseeinpcb to sys/netinet/in_prot.c in order to separate the
   INET and INET6-specific code from the rest of the prot code (It is only
   used by the network stack, so it makes sense for it to live with the
   other network stack code.)
 - Move cr_canseeinpcb prototype from sys/systm.h to netinet/in_systm.h
 - Rename cr_seeotheruids to cr_canseeotheruids and cr_seeothergids to
   cr_canseeothergids, make them non-static, and add prototypes (so they
   can be seen/called by in_prot.c functions.)
 - Remove sw_csum variable from ip6_forward in ip6_forward.c, as it is an
   unused variable.

Reviewed by:gnn, jtl
Approved by:sjg (mentor)
Sponsored by:   Juniper Networks, Inc.
Differential Revision:  https://reviews.freebsd.org/D2901

303410 by bdrewery:
Reconnect pmcstudy, lost in r291021

Reported by:pluknet
MFC after:  3 days
Sponsored by:   EMC / Isilon Storage Division

303406 by jhb:
Adjust tests in fsync job scheduling loop to reduce indentation.



The end of the build log:

[...truncated 139023 lines...]
===> usr.bin/indent (all)
--- all_subdir_usr.sbin ---
--- all_subdir_usr.sbin/ntp ---
--- dir.o ---
cc   -O2 -pipe -I/usr/src/usr.sbin/ntp/libntp/../../../contrib/ntp/include  
-I/usr/src/usr.sbin/ntp/libntp/../../../contrib/ntp/lib/isc/include  
-I/usr/src/usr.sbin/ntp/libntp/../../../contrib/ntp/lib/isc/unix/include  
-I/usr/src/usr.sbin/ntp/libntp/../../../contrib/ntp/lib/isc/pthreads/include  
-I/usr/src/usr.sbin/ntp/libntp/../../../contrib/ntp/sntp/libopts  
-I/usr/src/usr.sbin/ntp/libntp/../../../lib/libc/i386  
-I/usr/src/usr.sbin/ntp/libntp/../../../lib/libedit/edit  
-I/usr/src/usr.sbin/ntp/libntp/../  -I/usr/src/usr.sbin/ntp/libntp/ 
-DHAVE_BSD_NICE -DHAVE_STDINT_H   -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H  
-DOPENSSL -DUSE_OPENSSL_CRYPTO_RAND -DAUTOKEY -MD  -MF.depend.dir.o -MTdir.o 
-std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-p
 arameter -Wno-parentheses  -Qunused-arguments  -c 
/usr/src/usr.sbin/ntp/libntp/../../../contrib/ntp/lib/isc/unix/dir.c -o dir.o
--- all_subdir_usr.bin ---
--- .depend ---
echo indent.full: /usr/obj/usr/src/tmp/usr/lib/libc.a  >> .depend
--- indent.o ---
cc  -O2 -pipe   -g -MD  -MF.depend.indent.o -MTindent.o -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith

Re: EARLY_AP_STARTUP hangs during boot

2016-07-27 Thread John Baldwin 
On Tuesday, June 07, 2016 12:06:54 PM Gary Jennejohn wrote:
> On Tue, 31 May 2016 13:10:06 -0700
> John Baldwin  wrote:
> 
> > On Saturday, May 28, 2016 02:11:41 PM Gary Jennejohn wrote:
> > > On Fri, 27 May 2016 09:50:05 +0200
> > > Gary Jennejohn  wrote:
> > >   
> > > > On Thu, 26 May 2016 16:54:35 -0700
> > > > John Baldwin  wrote:
> > > >   
> > > > > On Tuesday, May 17, 2016 06:47:41 PM Gary Jennejohn wrote:
> > > > > > On Mon, 16 May 2016 10:54:19 -0700
> > > > > > John Baldwin  wrote:
> > > > > >   
> > > > > > > On Monday, May 16, 2016 12:22:42 PM Gary Jennejohn wrote:  
> > > > > > > > I tried out EARLY_AP_STARTUP, but the kernel hangs and I can't
> > > > > > > > break into DDB.
> > > > > > > > 
> > > > > > > > I did a verbose boot and the last lines I see are related to 
> > > > > > > > routing
> > > > > > > > MSI-X to various local APIC vectors.  I copied the last few 
> > > > > > > > lines and
> > > > > > > > they look like this:
> > > > > > > > 
> > > > > > > > msi: routing MSI-X IRQ 256 to local APIC 2 vector 48
> > > > > > > > msi: routing MSI-X IRQ 257 to local APIC 3 vector 48
> > > > > > > > msi: routing MSI-X IRQ 258 to local APIC 4 vector 48
> > > > > > > > msi: routing MSI-X IRQ 256 to local APIC 0 vector 49  
> > > > > >  ^^^ Assigning  
> > > > > > > > 
> > > > > > > > I tried disabling msi and msix in /boot/loader.conf, but the 
> > > > > > > > settings
> > > > > > > > were ignored (probabaly too early).
> > > > > > > 
> > > > > > > No, those settings are not too early.  However, the routing to 
> > > > > > > different
> > > > > > > CPUs now happens earlier than it used to.  What is the line 
> > > > > > > before the
> > > > > > > MSI lines?  You can take a picture with your phone/camera if 
> > > > > > > that's simplest.
> > > > > > >   
> > > > > > 
> > > > > > Here a few lines before the MSI routing happens:
> > > > > > 
> > > > > > hpet0:  iomem 0xfed0-0xfed003ff irq 
> > > > > > 0,8 on acpi0
> > > > > > hpet0: vendor 0x4353, rev 0x1, 14318180 Hz, 3 timers, legacy route
> > > > > > hpet0: t0 : irqs 0x00c0ff (0), MSI, periodic
> > > > > > hpet0: t1 : irqs 0x00c0ff (0), MSI, periodic
> > > > > > hpet0: t2 : irqs 0x00c0ff (0), MSI, periodic
> > > > > > Timecounter "HPET" frequency 14318180 Hz quality 950  
> > > > > 
> > > > > The assigning message means it is in the loop using
> > > > > bus_bind_intr() to setup per-CPU timers.  Can you please try
> > > > > setting 'hint.hpet.0.per_cpu=0' at the loader prompt to see if
> > > > > disabling the use of per-CPU timers allows you to boot?
> > > > > 
> > > > 
> > > > Something has changed since the last time I generated a kernel with
> > > > this option.
> > > > 
> > > > Now I get a NULL-pointer dereference in the kernel, doesn't matter
> > > > whether I set the hint or not.
> > > >   
> > > 
> > > OK, now that the startup has been fixed, I tried setting the hint at
> > > the loader prompt, but the kenel hangs in exactly the same place as
> > > before.  I actually booted twice to make certain I hadn't made a
> > > typo when setting the hint.  
> > 
> > Humm, it shouldn't be calling bus_bind_intr() if the hint is set.  Actually,
> > I guess it just binds them all to first CPU if per-CPU timers aren't set.
> > Can you add debug printfs to hpet_attach() in sys/dev/acpica/acpi_hpet.c to
> > narrow down which line in that function it hangs after?
> > 
> > Another option to try is to add the following to your kernel config:
> > 
> > options KTR
> > options KTR_COMPILE=KTR_PROC
> > options KTR_MASK=KTR_PROC
> > options KTR_VERBOSE=1
> > 
> > this will spew a lot of crap to the screen, but if it stops spewing when it
> > hangs then it might be tell us where the system is hung.  If you have any 
> > way
> > to configure a serial console then this would also be useful even if it 
> > spews
> > constantly when it is hung (assuming you could log the output of the serial
> > console).
> > 
> 
> I used the KTR options.
> 
> After the Timecounter "HPET" frequency 14318180 Hz quality 950 I see
> 
> cpu0 mi_switch: old thread 1 (swapper)
> cpu0 mi_switch: new thread 10022 (if_config_tqg_0)
> cpu0 sleep_broadcast(0x80002f9a600, 0)
> cpu0 msleep_spin: old thread 100022
> cpu0 mi_switch: old thread 10022
> cpu0 mi_switch: new thread 10016 (if_io_tqg_0)
> cpu0 sleep_broadcast(0x80002f9a780, 0)
> cpu0 msleep_spin: old thread 10016
> cpu0 mi_switch: old thread 10016
> cpu0 fork_exit: new thread 0x80004239510 (td_sched 0x842399d8, pid
> 10, idle: cpu0)
> 
> And that's all that came out, really not very much at all.

Ok, that seems odd.

Can you apply this patch and run with the KTR output still:

Index: sched_ule.c
===
--- sched_ule.c (revision 303397)
+++ sched_ule.c (working copy)
@@ -1904,6 +1904,13 @@ sched_switch(struct thread

Re: Possible race condition building libraries: head/amd64 r303329 -> r303379

2016-07-27 Thread Simon J. Gerraty 
David Wolfskill  wrote:
> The build failed (initially -- a restart worked):

That's usually a good indicator of a race.
___
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"

Possible race condition building libraries: head/amd64 r303329 -> r303379

2016-07-27 Thread David Wolfskill 
I track head daily on both my laptop and a "build machine;" I only saw a
problem on the latter -- not on my laptop.

(The build machine is a bit beefier, and uses an SSD as its non-volatile
storage; the laptop uses a hybrid disk -- in case that is useful.)

As indicated in the Subject, in each case I was performing a
source-based upgrade-in-place from r303329 to r303379.  (And I've
been doing this routinely for quite some time.)

The build failed (initially -- a restart worked):

...
>>> stage 4.2: building libraries
...
--- secure/lib/libcrypto__L ---
Building /common/S4/obj/usr/src/secure/lib/libcrypto/dso_openssl.o
--- lib/ncurses/ncursesw__L ---
/usr/lib/libtermlibw.so -> libncursesw.so
/usr/lib/libtinfow.so -> libncursesw.so
--- kerberos5/lib/libwind__L ---
Building /common/S4/obj/usr/src/kerberos5/lib/libwind/normalize_table.So
--- kerberos5/lib/libheimipcc__L ---
/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [libprivateheimipcc.so.11] Error code 1

bmake[4]: stopped in /usr/src/kerberos5/lib/libheimipcc
.ERROR_TARGET='libprivateheimipcc.so.11'
.ERROR_META_FILE='/common/S4/obj/usr/src/kerberos5/lib/libheimipcc/libprivateheimipcc.so.11.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/kerberos5/lib/libheimipcc'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/usr/obj/usr/src/kerberos5/lib/libheimipcc'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160604'
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/src/kerberos5/lib/libheimipcc/Makefile /usr/src/share/mk/bsd.lib.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk 
/usr/src/kerberos5/lib/libheimipcc/../Makefile.inc 
/usr/src/kerberos5/lib/libheimipcc/../../Makefile.inc 
/usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk 
/usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk 
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/kerberos5/lib/libheimipcc 
/usr/src/kerberos5/lib/libheimipcc/../../../crypto/heimdal/lib/ipc'
1 error

bmake[4]: stopped in /usr/src/kerberos5/lib/libheimipcc
.ERROR_TARGET='libprivateheimipcc.so.11'
.ERROR_META_FILE='/common/S4/obj/usr/src/kerberos5/lib/libheimipcc/libprivateheimipcc.so.11.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/kerberos5/lib/libheimipcc'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/usr/obj/usr/src/kerberos5/lib/libheimipcc'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160604'
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/src/kerberos5/lib/libheimipcc/Makefile /usr/src/share/mk/bsd.lib.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk 
/usr/src/kerberos5/lib/libheimipcc/../Makefile.inc 
/usr/src/kerberos5/lib/libheimipcc/../../Makefile.inc 
/usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk 
/usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk 
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.confs.mk

Re: FreeBSD 11.0-BETA2 won't boot on an Acer Aspire 5560

2016-07-27 Thread Kubilay Kocak 
On 27/07/2016 7:22 PM, Peter Jeremy wrote:
> I'm trying to boot the 11.0-BETA2/amd64 memory stick image and the
> kernel panics: (Following copied by hand):
> 
> ACPI APIC Table: 
> ...
> acpi0:  on motherboard
> ACPI Error: Hardware did not change modes (20160527/hwacpi-160)
> ACPI Error: Could not transition to APCI mode (20160527/evxfevnt-105)
> ACPI Warning: AcpiEnable failed (20160527/utxfinit-184)
> acpi0: Could not enable ACPI: AE_NO_HARDWARE_RESPONSE
> device_attach: acpi0 attach returned 6
> 
> Followed by a NULL dereference panic at nexus_acpi_attach+0x89
> 
> The system boots a 10.0-RELEASE/amd64 memstick (the only other image I
> have conveniently to date) without problem.
> 

Thank you for the report Peter

Did it boot prior to 11.0-BETA2? ie; is it a regression?

Please report a bug in bugzilla with version: 11.0-BETA2 and cc
r...@freebsd.org

If it's possible to obtain a backtrace of the panic, please include it
as an attachment:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html

Setting debug.debugger_on_panic=1 in loader may help get it to the debugger.


___
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 11.0-BETA2 won't boot on an Acer Aspire 5560

2016-07-27 Thread Peter Jeremy 
I'm trying to boot the 11.0-BETA2/amd64 memory stick image and the
kernel panics: (Following copied by hand):

ACPI APIC Table: 
...
acpi0:  on motherboard
ACPI Error: Hardware did not change modes (20160527/hwacpi-160)
ACPI Error: Could not transition to APCI mode (20160527/evxfevnt-105)
ACPI Warning: AcpiEnable failed (20160527/utxfinit-184)
acpi0: Could not enable ACPI: AE_NO_HARDWARE_RESPONSE
device_attach: acpi0 attach returned 6

Followed by a NULL dereference panic at nexus_acpi_attach+0x89

The system boots a 10.0-RELEASE/amd64 memstick (the only other image I
have conveniently to date) without problem.

-- 
Peter Jeremy


signature.asc
Description: PGP signature