FreeBSD Quarterly Status Report - Second Quarter 2016
-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. * Create and document baseline procedures and guideli
IWM(7260), no connect
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 Corporation' device = 'Sunrise Point-H PMC' class = memory hdac0@pci0:0:31:3: class=0x040300 card=0x07061028 chip=0xa1708086 rev=0x31 hdr=0x00 vendor = 'Intel Corporation' device = 'Sunrise Point-H HD Audio' class = multimedia subclass = HDA none5@pci0:0:31:4: class=0x0c0500 card=0x070610
Re: Boot environments and zfs canmount=noauto
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
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
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
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
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
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
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
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
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
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
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
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: cpu0) > > > > And that's all that came out, really not very much at all. > > Ok, that seems
FreeBSD_HEAD_i386 - Build #3701 - Failure
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 -Wreturn-
Re: EARLY_AP_STARTUP hangs during boot
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 *td, struct thread *new td->td_owepreempt = 0; if (!TD_IS_IDLETH
Re: Possible race condition building libraries: head/amd64 r303329 -> r303379
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
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 /usr/src/s
Re: FreeBSD 11.0-BETA2 won't boot on an Acer Aspire 5560
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
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