Re: Is NextBSD safe for bhyve?

[Outback Dingo]

On Thu, Aug 27, 2015 at 5:15 PM, Russell Haley russ.ha...@gmail.com wrote:

 Is NextBSD safe for bhyve?

 Thanks


Consider that everything CURRENT, can be somewhat volatile at times, I
wouldnt recommend it for a production business case.
However that being said I do have XEN/NextBSD running as a dom0 quite well,
iocage, behyve and others are being reveiwed
for use cases, at this state of flux your mileage may vary depending on
exactly what your using it for, localized testing and
running a few vms, Ive accomplished that much with XEN so far. But again,
it is based on CURRENT with alot of additions
being merged in and worked on daily.



 Russ
 ___
 freebsd-current@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

FreeBSD_HEAD - Build #3134 - Fixed

[jenkins-admin]

FreeBSD_HEAD - Build #3134 - Fixed:

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

Change summaries:

287200 by jch:
Silent a compilation warning on callout_stop()

287198 by jch:
In callout_stop(), do not forget to initialize not_running variable.
Thanks to hselasky for noticing that.

Differential Revision:  https://reviews.freebsd.org/D3078 (Updated)
Submitted by:   hselasky
Pointy hat to:  jch

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

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

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

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

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

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

Reviewed by:adrian
Sponsored by:   Netflix
Sponsored by:   Nginx, Inc.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [head up!] WiFi drivers changes

[Gleb Smirnoff]

  Good news, thanks!

On Thu, Aug 27, 2015 at 06:45:14PM +0200, O. Hartmann wrote:
O sory, sorry - I forgot on that specific machine (1 of 5) to mergemaster :-( 
So, after
O mergemaster, the new rc scripts also got installed on the AP server and the 
interface is
O again up and running!
O 
O Regards,
O 
O oh



-- 
Totus tuus, Glebius.
___
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: Instant panic while trying run ports-mgmt/poudriere

[John-Mark Gurney]

Andriy Gapon wrote this message on Thu, Aug 27, 2015 at 10:21 +0300:
 On 27/08/2015 02:36, John-Mark Gurney wrote:
  We should/cannot get here w/ an empty list.  If we do, then there is
  something seriously wrong...  The current kn (which we must have as we
  are here) MUST be on the list, but as you just showed, there are no
  knotes on the list.
  
  Can you get me a print of the knote?  That way I can see what flags
  are on it?
 
 Apologies if the following might sound a little bit patronizing, but it
 seems that you have got all the facts correctly, but somehow the
 connection between them did not become clear.
 
 So:
 1. The list originally is NOT empty.  I guess that it has one entry, but
 that's an unimportant detail.
 2. This is why the loop is entered. It's a fact that it is entered.
 3. The list becomes empty precisely because the entry is removed during
 the iteration in the loop (as kib has explained).  It's a fact that the
 list became empty at least in the panic that I reported.

On you're latest dump, you said:
Here is another +1 with r286922.
I can add a couple of bits of debugging data:   

(kgdb) fr 8 
#8  0x80639d60 in knote (list=0xf8019a733ea0,   
hint=2147483648, lockflags=value optimized out) at
/usr/src/sys/kern/kern_event.c:1964 
1964} else if ((lockflags  KNF_NOKQLOCK) != 0) {   

First off, that can't be r286922, per:
https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_event.c?annotate=286922

line 1964 is blank...  The line of code above should be at line 1884,
so not sure what is wrong here...

Assuming that the pc really is at the line, f_event has not yet been
called, which is why I said that the list cannot be empty yet, as
f_event hasn't been called yet to remove the knote...  It could be that
optimization moved stuff around, but if that is the case, then the
above wasn't useful..

 4. The element is not only unlinked from the list, but its memory is
 also freed.

Where is the memory freed?  A knote MUST NOT be freed in an f_event
handler.  The only location that a list element is allowed to be
freed is in knote_drop, which must happen after f_detach is called,
but that can't/won't happen from knote (I believe the timer handles
this specially, but we are talking about normal knlist type filters)..

The rest of your explination is invalid due to the invalid assumption
of this point...

If you can provide to me where the knote is free'd in knote, w/
function/line number stack trace (does not have to be dump, but a
sample call path), then I'll reconsider, and fix that bug...
 5. That's why we have the use after free: SLIST_FOREACH is trying to get
 a pointer to a next element from the freed memory.
 6. This is why the commit for trashing the freed memory made all the
 difference: previously the freed memory was unlikely to be re-used /
 modified, so the use-after-free had a high chance of succeeding.  It's a
 fact that in my panic there was an attempt to dereference a trashed pointer.
 7. Finally, this is why SLIST_FOREACH_SAFE helps here: we stash the
 pointer to the next element beforehand and, thus, we do not access the
 freed memory.
 
 Please let me know if you see any fault in above reasoning or if
 something is still no clear.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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_HEAD - Build #3135 - Failure

[jenkins-admin]

FreeBSD_HEAD - Build #3135 - Failure:

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

Change summaries:

287214 by andrew:
There is no need to get the bus tag or handle.

Sponsored by:   ABT Systems Ltd

287213 by andrew:
Limit the speed to the bus frequency.

Sponsored by:   ABT Systems Ltd

287212 by andrew:
Allow the fifo-depth and num-slots to be missing. For the former we read
the value from the hardware, for the latter assume a single slot.

Sponsored by:   ABT Systems Ltd

287211 by bz:
get_inpcbinfo() and get_pcblist() are UDP local functions and
do not do what one would expect by name. Prefix them with udp_
to at least obviously limit the scope.

This is a non-functional change.

Reviewed by:gnn, rwatson
MFC after:  2 weeks
Differential Revision:  https://reviews.freebsd.org/D3505

287209 by ed:
Decompose linkat()/renameat() rights to source and target.

To make it easier to understand how Capsicum interacts with linkat() and
renameat(), rename the rights to CAP_{LINK,RENAME}AT_{SOURCE,TARGET}.

This also addresses a shortcoming in Capsicum, where it isn't possible
to disable linking to files stored in a directory. Creating hardlinks
essentially makes it possible to access files with additional rights.

Reviewed by:rwatson, wblock
Differential Revision:  https://reviews.freebsd.org/D3411

287208 by ume:
Make it buildable with WITH_OPENLDAP, again.

MFC after:  1 week

287206 by kan:
Repair sys/cdefs.h enough to be usable with GCC 5.x

The __alloc_size and __alloc_align need to be defined to
nothingness for lint, but the existing check is deficient
and allows attributes with working __has_attrubute() to
slip through.

287205 by kan:
Make ncurses build with GCC 5.0 and up

Merge the end result of two upstream changes:

Original fix from 20141206:
  + modify MKlib_gen.sh to work around change in development version of
gcc introduced here:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02185.html
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00236.html
(reports by Marcus Shawcroft, Maohui Lei).

Later fixed in different manner in 20150725:
  + use alternate workaround for gcc 5.x feature (adapted from patch by
Mikhail Peselnik).

287204 by kan:
Unbreak nvi message catalog generation for 8 bit locales.

Feeding any file encoded in 8 bit locales such as KOI8-RU
to sort utility running under UTF-8 locale produces astonishing
result of recoding the output to UTF-8. To counter that, just
run sort under 'C' locale for now.

287202 by andrew:
Allow us to select the transfer count. This allows us to work with hardware
that seems to only work with a single block at a time.

Sponsored by:   ABT Systems Ltd



The end of the build log:

[...truncated 59031 lines...]
echo clang: /usr/lib/libc++.a  .depend
--- all_subdir_clang ---
--- all_subdir_clang-tblgen ---
--- all_subdir_tblgen ---
--- all_subdir_clang ---
=== usr.bin/clang/clang (all)
--- all_subdir_clang-tblgen ---
=== usr.bin/clang/clang-tblgen (all)
--- all_subdir_tblgen ---
=== usr.bin/clang/tblgen (all)
--- all_subdir_clang ---
--- cc1_main.o ---
--- cc1as_main.o ---
--- driver.o ---
--- cc1_main.o ---
c++ -O2 -pipe 
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/include 
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include
 
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver
 -I. 
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd11.0\ 
-DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ 
-DDEFAULT_SYSROOT=\/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp\ 
-Qunused-arguments 
-I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/include  
-std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c 
/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/cc1_main.cpp
 -o cc1_main.o
--- cc1as_main.o ---
c++ -O2 -pipe 
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/include 
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include
 
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver
 -I. 
-I/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\x86_64-unknown-freebsd11.0\ 
-DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ 
-DDEFAULT_SYSROOT=\/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp\ 
-Qunused-arguments 

Re: [head up!] WiFi drivers changes

[Gleb Smirnoff]

  Oliver,

O Again,
O with the most recent changes as of r287211, hostapd doens't start my WiFi AP 
anymore
O (FreeBSD 11.0-CURRENT #7 r287169: Wed Aug 26 20:26:49 CEST 2015 amd64 does!).

Let's start investigating from scratch, since the /etc part of the
patch have changed significantly.

Can you please send me privately your configs and debug log of hostapd?

[Adding pluknet@ to Cc, who helped a lot with testing the hostap support
during patch development]

-- 
Totus tuus, Glebius.
___
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: [head up!] WiFi drivers changes

[O. Hartmann]

Am Thu, 27 Aug 2015 18:32:53 +0200
O. Hartmann ohart...@zedat.fu-berlin.de schrieb:

 Am Fri, 7 Aug 2015 16:50:23 -0700
 Adrian Chadd adrian.ch...@gmail.com schrieb:
 
  Hi,
  
  Gleb/others doing this: you have 4 days to figure out what's wrong
  with things, or I'm backing all of this work out.
  
  Thanks,
  
  
  -adrian
  
  
  On 7 August 2015 at 08:52, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
   Am Thu, 6 Aug 2015 18:13:55 +0300
   Gleb Smirnoff gleb...@freebsd.org schrieb:
  
 Hi!
  
 As part of the opaque ifnet project [1], all 802.11 (WiFi) drivers
   undergo change of not being an interface anymore. Historically in FreeBSD
   802.11 stack, 802.11 devices called if_attach() and created an interface.
   Later this was generalized and real functioning interface is created by
   net80211 stack. However, remnant of parent interface remained. If you
   are running Intel Centrino wireless, then you got iwn0 interface and
   wlan0 interface. However, the former doesn't do anything. You can't
   assign addresses to it or modify any of it parameters. Or you can
   modify them, but that affects nothing.
  
   This superfluous ifnet on the list entangles the net80211 stack and
   also is on the way of [1]. So, decision was made to remove it. I
   already did preparatory commits back in May, and now it is time to
   finish that.
  
   The patch is:
  
   https://reviews.freebsd.org/D2655
  
   And the Wiki page for it is:
  
   https://wiki.freebsd.org/projects/ifnet/net80211
  
   The patch modifies every driver, and diff is bulky. However, changes
   are mechanical and simple, most drivers appeared to work after first
   run. Most converted drivers are tested to work.
  
   This is list of drivers that are not tested, due to lack of testers:
  
 mwl, ipw, bwn, wi, upgt, uath.
  
   But, as said, changes are mechanical and probability is 95% that
   they will work.
  
   The only complex one is ndis(4). It could be broken by conversion.
   Since I already got a tester volunteer, I will fix it quickly if
   anything happens.
  
   Another untrivial one is wtap(4), which is not connected to the
   build and appeared to be broken even before conversion. Anyway,
   I made it compilable.
  
   Now, for the configuration. The sequence of commands you need
   to run to configure a WiFi interface doesn't change. As before
   it is:
  
   ifconfig wlan0 create wlandev iwn0
   ifconfig wlan0 $foo
  
   Your rc.conf doesn't need any changes. As before:
  
   wlans_iwn0=wlan0
   ifconfig_wlan0=DHCP WPA
  
   However, iwn0 disappeared from the 'ifconfig -l'. It is still
   in devinfo, or in dmesg. For the sake of installers or other
   configuration software, a sysctl is provided:
  
   net.wlan.devices: iwn0
  
   The /etc subsystem needs to be tweaked. Previously the wlan(4)
   interfaces were created in childif_create(), and the script
   did check for presence of parent interface. In my patch I
   provided wlans_up(), that doesn't check. The code in D2655
   now works correctly both on patched and on unpatched kernel.
  
   Alternatively, I could tweak childif_create() to use net.wlan.devices
   instead of 'ifconfig -l'. Or, to use them both, to work on older
   and on newer kernels?
  
   I am not sure which path with /etc is better, so seeking for
   help with that.
  
  
   After updating to FreeBSD 11.0-CURRENT #0 r286415: Fri Aug  7 17:22:43 
   CEST 2015
   amd64, several APs won't startup anymore:
  
   [...]
   Starting hostapd.
   Configuration file: /etc/hostapd.conf
   bsd_set_if_media: SIOCSIFMEDIA Device not configured
   bsd_init: failed to set operation mode
   bsd driver initialization failed.
   wlan0: interface state UNINITIALIZED-DISABLED
   wlan0: AP-DISABLED
   hostapd_free_hapd_data: Interface wlan0 wasn't started
   ELOOP: remaining socket: sock=5 eloop_data=0x801c47100 user_data=0x0
   handler=0x41a0e0 /etc/rc.d/hostapd: WARNING: failed to start hostapd
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 
 Again,
 with the most recent changes as of r287211, hostapd doens't start my WiFi AP 
 anymore
 (FreeBSD 11.0-CURRENT #7 r287169: Wed Aug 26 20:26:49 CEST 2015 amd64 does!).

Ups,

sory, sorry - I forgot on that specific machine (1 of 5) to mergemaster :-( So, 
after
mergemaster, the new rc scripts also got installed on the AP server and the 
interface is
again up and running!

Regards,

oh


pgpxHmF8Um9ku.pgp
Description: OpenPGP digital signature

Re: [head up!] WiFi drivers changes

[O. Hartmann]

Am Fri, 7 Aug 2015 16:50:23 -0700
Adrian Chadd adrian.ch...@gmail.com schrieb:

 Hi,
 
 Gleb/others doing this: you have 4 days to figure out what's wrong
 with things, or I'm backing all of this work out.
 
 Thanks,
 
 
 -adrian
 
 
 On 7 August 2015 at 08:52, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
  Am Thu, 6 Aug 2015 18:13:55 +0300
  Gleb Smirnoff gleb...@freebsd.org schrieb:
 
Hi!
 
As part of the opaque ifnet project [1], all 802.11 (WiFi) drivers
  undergo change of not being an interface anymore. Historically in FreeBSD
  802.11 stack, 802.11 devices called if_attach() and created an interface.
  Later this was generalized and real functioning interface is created by
  net80211 stack. However, remnant of parent interface remained. If you
  are running Intel Centrino wireless, then you got iwn0 interface and
  wlan0 interface. However, the former doesn't do anything. You can't
  assign addresses to it or modify any of it parameters. Or you can
  modify them, but that affects nothing.
 
  This superfluous ifnet on the list entangles the net80211 stack and
  also is on the way of [1]. So, decision was made to remove it. I
  already did preparatory commits back in May, and now it is time to
  finish that.
 
  The patch is:
 
  https://reviews.freebsd.org/D2655
 
  And the Wiki page for it is:
 
  https://wiki.freebsd.org/projects/ifnet/net80211
 
  The patch modifies every driver, and diff is bulky. However, changes
  are mechanical and simple, most drivers appeared to work after first
  run. Most converted drivers are tested to work.
 
  This is list of drivers that are not tested, due to lack of testers:
 
mwl, ipw, bwn, wi, upgt, uath.
 
  But, as said, changes are mechanical and probability is 95% that
  they will work.
 
  The only complex one is ndis(4). It could be broken by conversion.
  Since I already got a tester volunteer, I will fix it quickly if
  anything happens.
 
  Another untrivial one is wtap(4), which is not connected to the
  build and appeared to be broken even before conversion. Anyway,
  I made it compilable.
 
  Now, for the configuration. The sequence of commands you need
  to run to configure a WiFi interface doesn't change. As before
  it is:
 
  ifconfig wlan0 create wlandev iwn0
  ifconfig wlan0 $foo
 
  Your rc.conf doesn't need any changes. As before:
 
  wlans_iwn0=wlan0
  ifconfig_wlan0=DHCP WPA
 
  However, iwn0 disappeared from the 'ifconfig -l'. It is still
  in devinfo, or in dmesg. For the sake of installers or other
  configuration software, a sysctl is provided:
 
  net.wlan.devices: iwn0
 
  The /etc subsystem needs to be tweaked. Previously the wlan(4)
  interfaces were created in childif_create(), and the script
  did check for presence of parent interface. In my patch I
  provided wlans_up(), that doesn't check. The code in D2655
  now works correctly both on patched and on unpatched kernel.
 
  Alternatively, I could tweak childif_create() to use net.wlan.devices
  instead of 'ifconfig -l'. Or, to use them both, to work on older
  and on newer kernels?
 
  I am not sure which path with /etc is better, so seeking for
  help with that.
 
 
  After updating to FreeBSD 11.0-CURRENT #0 r286415: Fri Aug  7 17:22:43 CEST 
  2015
  amd64, several APs won't startup anymore:
 
  [...]
  Starting hostapd.
  Configuration file: /etc/hostapd.conf
  bsd_set_if_media: SIOCSIFMEDIA Device not configured
  bsd_init: failed to set operation mode
  bsd driver initialization failed.
  wlan0: interface state UNINITIALIZED-DISABLED
  wlan0: AP-DISABLED
  hostapd_free_hapd_data: Interface wlan0 wasn't started
  ELOOP: remaining socket: sock=5 eloop_data=0x801c47100 user_data=0x0 
  handler=0x41a0e0
  /etc/rc.d/hostapd: WARNING: failed to start hostapd
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Again,
with the most recent changes as of r287211, hostapd doens't start my WiFi AP 
anymore
(FreeBSD 11.0-CURRENT #7 r287169: Wed Aug 26 20:26:49 CEST 2015 amd64 does!).


pgpbG0rBYoX3z.pgp
Description: OpenPGP digital signature

Re: Instant panic while trying run ports-mgmt/poudriere

[Andriy Gapon]

On 27/08/2015 23:21, Andriy Gapon wrote:
  First off, that can't be r286922, per:
  https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_event.c?annotate=286922
  
  line 1964 is blank...  The line of code above should be at line 1884,
  so not sure what is wrong here...
 No, it can not be indeed, because I am running head.
 r286922 was the latest version of the repository, not the head branch,
 at the moment when I pulled the repository via git.


Hrm, a small - irrelevant for me, but probably not for you - nit:
r286922 is actually a head commit:
https://svnweb.freebsd.org/base?view=revisionrevision=286922

And:
https://svnweb.freebsd.org/base/head/sys/kern/kern_event.c?annotate=286922#l1964

Not sure why you chose to look at stable/10 (given the mailing list).

-- 
Andriy Gapon
___
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: Instant panic while trying run ports-mgmt/poudriere

[Andriy Gapon]

On 27/08/2015 21:09, John-Mark Gurney wrote:
 Andriy Gapon wrote this message on Thu, Aug 27, 2015 at 10:21 +0300:
 On 27/08/2015 02:36, John-Mark Gurney wrote:
 We should/cannot get here w/ an empty list.  If we do, then there is
 something seriously wrong...  The current kn (which we must have as we
 are here) MUST be on the list, but as you just showed, there are no
 knotes on the list.

 Can you get me a print of the knote?  That way I can see what flags
 are on it?

 Apologies if the following might sound a little bit patronizing, but it
 seems that you have got all the facts correctly, but somehow the
 connection between them did not become clear.

 So:
 1. The list originally is NOT empty.  I guess that it has one entry, but
 that's an unimportant detail.
 2. This is why the loop is entered. It's a fact that it is entered.
 3. The list becomes empty precisely because the entry is removed during
 the iteration in the loop (as kib has explained).  It's a fact that the
 list became empty at least in the panic that I reported.
 
 On you're latest dump, you said:
 Here is another +1 with r286922.  
   
 I can add a couple of bits of debugging data: 
   
   
   
 (kgdb) fr 8   
   
 #8  0x80639d60 in knote (list=0xf8019a733ea0, 
   
 hint=2147483648, lockflags=value optimized out) at  
   
 /usr/src/sys/kern/kern_event.c:1964   
   
 1964} else if ((lockflags  KNF_NOKQLOCK) != 0) { 
   
 
 First off, that can't be r286922, per:
 https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_event.c?annotate=286922
 
 line 1964 is blank...  The line of code above should be at line 1884,
 so not sure what is wrong here...

No, it can not be indeed, because I am running head.
r286922 was the latest version of the repository, not the head branch,
at the moment when I pulled the repository via git.

 Assuming that the pc really is at the line, f_event has not yet been
 called,

Even on the second loop iteration?

which is why I said that the list cannot be empty yet, as
 f_event hasn't been called yet to remove the knote...  It could be that
 optimization moved stuff around, but if that is the case, then the
 above wasn't useful..

I provided the disassembly of the code as well, it's very obvious how
the code was translated.

 4. The element is not only unlinked from the list, but its memory is
 also freed.
 
 Where is the memory freed?  A knote MUST NOT be freed in an f_event
 handler.  The only location that a list element is allowed to be
 freed is in knote_drop, which must happen after f_detach is called,
 but that can't/won't happen from knote (I believe the timer handles
 this specially, but we are talking about normal knlist type filters)..

Well, right.  knote()-filt_proc()-knlist_remove_inevent() just removes
the knote from the list.  But then there is KNOTE_ACTIVATE() that passes
the knote to a different owner (so to say). And given that the knote has
EV_ONESHOT set on it (in filt_proc) and that poudriere can put quite a
stress load on a system, I am not surprised that another thread gets a
chance to call knote_drop() on the knote before the original thread
proceeds to the next iteration.

 The rest of your explination is invalid due to the invalid assumption
 of this point...

Eagerly waiting for your explanation...

 If you can provide to me where the knote is free'd in knote, w/
 function/line number stack trace (does not have to be dump, but a
 sample call path), then I'll reconsider, and fix that bug...
 5. That's why we have the use after free: SLIST_FOREACH is trying to get
 a pointer to a next element from the freed memory.
 6. This is why the commit for trashing the freed memory made all the
 difference: previously the freed memory was unlikely to be re-used /
 modified, so the use-after-free had a high chance of succeeding.  It's a
 fact that in my panic there was an attempt to dereference a trashed pointer.
 7. Finally, this is why SLIST_FOREACH_SAFE helps here: we stash the
 pointer to the next element beforehand and, thus, we do not access the
 freed memory.

 Please let me know if you see any fault in above reasoning or if
 something is still no clear.
 


-- 
Andriy Gapon
___
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_HEAD - Build #3136 - Fixed

[jenkins-admin]

FreeBSD_HEAD - Build #3136 - Fixed:

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

Change summaries:

287218 by jmg:
add documentation for timers that silby added in r197244, almost 6 years
ago...

287217 by delphij:
die() would never return, mark it as so.

MFC after:  2 weeks

287216 by ume:
Move setting of LDFLAGS to the modules which require it actually, as
other kerberos5 modules do so.

___
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: Instant panic while trying run ports-mgmt/poudriere

[Konstantin Belousov]

On Thu, Aug 27, 2015 at 11:09:45AM -0700, John-Mark Gurney wrote:
 Andriy Gapon wrote this message on Thu, Aug 27, 2015 at 10:21 +0300:
  On 27/08/2015 02:36, John-Mark Gurney wrote:
   We should/cannot get here w/ an empty list.  If we do, then there is
   something seriously wrong...  The current kn (which we must have as we
   are here) MUST be on the list, but as you just showed, there are no
   knotes on the list.
   
   Can you get me a print of the knote?  That way I can see what flags
   are on it?
  
  Apologies if the following might sound a little bit patronizing, but it
  seems that you have got all the facts correctly, but somehow the
  connection between them did not become clear.
  
  So:
  1. The list originally is NOT empty.  I guess that it has one entry, but
  that's an unimportant detail.
  2. This is why the loop is entered. It's a fact that it is entered.
  3. The list becomes empty precisely because the entry is removed during
  the iteration in the loop (as kib has explained).  It's a fact that the
  list became empty at least in the panic that I reported.
 
 On you're latest dump, you said:
 Here is another +1 with r286922.  
   
 I can add a couple of bits of debugging data: 
   
   
   
 (kgdb) fr 8   
   
 #8  0x80639d60 in knote (list=0xf8019a733ea0, 
   
 hint=2147483648, lockflags=value optimized out) at  
   
 /usr/src/sys/kern/kern_event.c:1964   
   
 1964} else if ((lockflags  KNF_NOKQLOCK) != 0) { 
   
 
 First off, that can't be r286922, per:
 https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_event.c?annotate=286922
 
 line 1964 is blank...  The line of code above should be at line 1884,
 so not sure what is wrong here...
 
 Assuming that the pc really is at the line, f_event has not yet been
 called, which is why I said that the list cannot be empty yet, as
 f_event hasn't been called yet to remove the knote...  It could be that
 optimization moved stuff around, but if that is the case, then the
 above wasn't useful..
 
  4. The element is not only unlinked from the list, but its memory is
  also freed.
 
 Where is the memory freed?  A knote MUST NOT be freed in an f_event
 handler.  The only location that a list element is allowed to be
 freed is in knote_drop, which must happen after f_detach is called,
 but that can't/won't happen from knote (I believe the timer handles
 this specially, but we are talking about normal knlist type filters)..
 
 The rest of your explination is invalid due to the invalid assumption
 of this point...
 
 If you can provide to me where the knote is free'd in knote, w/
 function/line number stack trace (does not have to be dump, but a
 sample call path), then I'll reconsider, and fix that bug...
Sigh.  Did you ever read the mails I sent ?

Look at the filt_proc()-knlist_remove_inevent().

  5. That's why we have the use after free: SLIST_FOREACH is trying to get
  a pointer to a next element from the freed memory.
  6. This is why the commit for trashing the freed memory made all the
  difference: previously the freed memory was unlikely to be re-used /
  modified, so the use-after-free had a high chance of succeeding.  It's a
  fact that in my panic there was an attempt to dereference a trashed pointer.
  7. Finally, this is why SLIST_FOREACH_SAFE helps here: we stash the
  pointer to the next element beforehand and, thus, we do not access the
  freed memory.
  
  Please let me know if you see any fault in above reasoning or if
  something is still no clear.
 
 -- 
   John-Mark GurneyVoice: +1 415 225 5579
 
  All that I will do, has been done, All that I have, has not.
 ___
 freebsd-current@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Why does netstat not work in jails?

[Chris H]

On Fri, 28 Aug 2015 08:12:53 +0300 Alexander V. Chernikov melif...@ipfw.ru
wrote

 28.08.2015, 04:56, Chris H bsd-li...@bsdforge.com:
  I've been attempting to run jails on an 11-CURRENT
  for the purpose of building world/kernel  ports
  for all of our 9-STABLE production servers. I'm using
  standard/classic jail setup(s) -- not using any
  of the convenience ports/applications that abstract
  the process in any way.
  While everything seemed to go as intended/anticipated,
  I'm seeing things I *didn't* expect.
  The host network get's it's public IP from the router
  in front of it. From the router, I insure that it is
  allocated the same non-public IP everytime. So DHCP
  assigns it 192.168.0.100. I assigned the jail 192.168.0.103.
  SSHD is started within the jail, root IS allowed login.
  But any attempt to ssh to 192.168.0.103 from the host,
  returns:
  ssh_exchange_identification: Connection closed by remote host.
 
  SSHD id NOT running on the host.
 
  inetd_flags=-wW -a 192.168.0.100 and syslogd_flags=-ss
  is set on the host via rc.conf
 
  second issue; loging into the jail, via jexex. If I perform:
  netstat -nr
  The following is returned:
  netstat: kvm not available: /dev/mem: No such file or directory
  Routing tables
  rt_tables: symbol not in namelist
 
  Any thought's jump out at anyone?
 Direct kvm interface was removed from head a year ago.
 What you can do is recompiling netstat binary from 9 with NewTree variable
 defined to 1 and see if this helps. Output will look  a bit different, but
 you'll be able to see routing tables from jail.
 https://svnweb.freebsd.org/base/stable/9/usr.bin/netstat/route.c?revision=242
 025view=markup#l122 

 Another option is merging r261207 and r263335.

Perfect! That explains it.

Thank you, Alexander!

--Chris

--


___
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_HEAD_amd64_gcc4.9 - Build #387 - Failure

[jenkins-admin]

FreeBSD_HEAD_amd64_gcc4.9 - Build #387 - Failure:

Build information: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/387/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/387/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/387/console

Change summaries:

287237 by delphij:
Respect locale settings.

MFC after:  2 weeks

287236 by delphij:
Use exit() instead of return in main().

MFC after:  2 weeks

287235 by markj:
Remove weighted page handling from vm_page_advise().

This was added in r51337 as part of the implementation of
madvise(MADV_DONTNEED).  Its objective was to ensure that the page daemon
would eventually reclaim other unreferenced pages (i.e., unreferenced pages
not touched by madvise()) from the active queue.

Now that the pagedaemon performs steady scanning of the active page queue,
this weighted handling is unnecessary.  Instead, always cache clean pages
by moving them to the head of the inactive page queue.  This simplifies the
implementation of vm_page_advise() and eliminates the fragmentation that
resulted from the distribution of pages among multiple queues.

Suggested by:   alc
Reviewed by:alc
Sponsored by:   EMC / Isilon Storage Division
Differential Revision:  https://reviews.freebsd.org/D3401

287234 by markj:
Re-apply r274569. It was reverted in r276848 since that appeared to fix
some ctfmerge crashes that started to occur on i386 weeks after r274569 was
committed. Some later investigation indicated that the crashes were caused
by malformed CTF info that led to a stack overflow. The issue with CTF
info in i386 kernels seems to have been resolved by r261246, which updated
libdwarf and libelf.

r274569 fixes a bug which caused duplicate types to appear in the kernel's
CTF info. This duplication generally does not cause problems when using
DTrace, but makes it easier to hit the limit of 2^15 - 1 distinct type
definitions in a CTF container.

MFC after:  2 weeks

287233 by markj:
Remove an unneeded instruction.

MFC after:  1 week

287232 by markj:
nv.h lives in sys/ as of r279439.

287227 by imp:
Use CFLAGS_NO_SIMD in preference to varying lists of -mno- flags.
Go ahead and defined -D_STANDALONE for all targets (only strictly
needed for some architecture, but harmless on those it isn't required
for). Also add -msoft-float to all architectures uniformly rather
that higgley piggley like it is today.

Differential Revision: https://reviews.freebsd.org/D3496

287225 by imp:
New 1-Wire bus implementation. 1-Wire controller is abstracted, though
only gpiobus configured via FDT is supported. Bus enumeration is
supported. Devices are created for each device found. 1-Wire
temperature controllers are supported, but other drivers could be
written. Temperatures are polled and reported via a sysctl.  Errors
are reported via sysctl counters. Mis-wired bus detection is included
for more trouble shooting. See ow(4), owc(4) and ow_temp(4) for
details of what's supported and known issues.

This has been tested on Raspberry Pi-B, Pi2 and Beagle Bone Black
with up to 7 devices.

Differential Revision: https://reviews.freebsd.org/D2956
Relnotes: yes
MFC after: 2 weeks
Reviewed by: loos@ (with many insightful comments)

287224 by imp:
Document bsd.endian.mk.

287222 by kp:
pf: Remove support for 'scrub fragment crop|drop-ovl'

The crop/drop-ovl fragment scrub modes are not very useful and likely to confuse
users into making poor choices.
It's also a fairly large amount of complex code, so just remove the support
altogether.

Users who have 'scrub fragment crop|drop-ovl' in their pf configuration will be
implicitly converted to 'scrub fragment reassemble'.

Reviewed by:gnn, eri
Relnotes:   yes
Differential Revision:  https://reviews.freebsd.org/D3466



The end of the build log:

[...truncated 165633 lines...]
/usr/local/x86_64-freebsd/bin/ranlib -D libficl.a
=== sys/boot/i386 (all)
make[5]: /builds/FreeBSD_HEAD_amd64_gcc4.9/sys/boot/i386/Makefile line 16: 
warning: Skipping boot2 with gcc 40902
make[5]: /builds/FreeBSD_HEAD_amd64_gcc4.9/sys/boot/i386/Makefile line 20: 
warning: SUBDIR is mbr pmbr boot0 boot0sio btx cdboot gptboot kgzldr libi386 
libfirewire loader pxeldr zfsboot gptzfsboot zfsloader
--- _sub.all ---
=== sys/boot/i386/mbr (all)
--- mbr.o ---
/usr/local/x86_64-freebsd/bin/as  --defsym FLAGS=0x80 --32 -o mbr.o 
/builds/FreeBSD_HEAD_amd64_gcc4.9/sys/boot/i386/mbr/mbr.s
--- lib.all__D ---
--- ulog_login_pseudo.po ---
/usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem 
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include
 
-L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib
 
--sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp
 -B/usr/local/x86_64-freebsd/bin/ -pg  -O2 -pipe   -std=gnu99 -fstack-protector 
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes 

Why does netstat not work in jails?

[Chris H]

I've been attempting to run jails on an 11-CURRENT
for the purpose of building world/kernel  ports
for all of our 9-STABLE production servers. I'm using
standard/classic jail setup(s) -- not using any
of the convenience ports/applications that abstract
the process in any way.
While everything seemed to go as intended/anticipated,
I'm seeing things I *didn't* expect.
The host network get's it's public IP from the router
in front of it. From the router, I insure that it is
allocated the same non-public IP everytime. So DHCP
assigns it 192.168.0.100. I assigned the jail 192.168.0.103.
SSHD is started within the jail, root IS allowed login.
But any attempt to ssh to 192.168.0.103 from the host,
returns:
ssh_exchange_identification: Connection closed by remote host.

SSHD id NOT running on the host.

inetd_flags=-wW -a 192.168.0.100 and syslogd_flags=-ss
is set on the host via rc.conf

second issue; loging into the jail, via jexex. If I perform:
netstat -nr
The following is returned:
netstat: kvm not available: /dev/mem: No such file or directory
Routing tables
rt_tables: symbol not in namelist

Any thought's jump out at anyone?

Thanks!

--Chris

--


___
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: ramblings.. or not

[Craig Rodrigues]

On Wed, Aug 26, 2015 at 8:44 PM, Julian Elischer jul...@freebsd.org wrote:

 I just enjoyed the following video.

   http://nextbsd.org/jordan-hubbard-visits-bafug/


That is a very good video.  It is good to see the NextBSD folks pushing
the boundaries and innovating with BSD.  A lot of the Apple technologies
have been battle tested by millions of users, so if FreeBSD can benefit
from themwhy not?



 Do we have a standard path for ideas from these projects and DragonFly?


From what I can tell, there is no official standard path for getting
anything into FreeBSD.
Ideally, people should bring up ideas and discuss things on the mailing
lists
beforehand.
That usually happens, but not always.

At the end of the day, getting things into FreeBSD involves someone
with a commit bit, who is motivated to slam the code into the tree.
Occasionally there are problems, but for the most part, things seem to work
out, and we've gotten cool things like ZFS, Dtrace, Netmap, etc.

At the end of Jordan's video, he mentioned that while it took him a while to
get accustomed to git, he realizes that git and git ecosystems like GitHub
greatly facilitate interacting with an open source project.  Forking,
submitting patches,
etc. are greatly




 We should also do a better job of productising and incorporating GSOC
 work..


Definitely!  It's sad to see people put a lot of working into something via
GSOC,
and then have the work die on the vine once the summer is over.



 Maybe we should make the ideas page more mainline.  Where people can put
 in a more standard way links to their pet projects and offically submit
 work for inclusion.
 and then make it better known..


I've been working with a software developer in Egypt, Ahmed Kamal, who has
helped
me a lot with devops issues in the Jenkins cluster.  Ahmed attended BSDCan
this year
and is eager to help out.  Many thanks to FreeBSD Foundation for giving him
a travel grant!

One comment that Ahmed made to me, and also to the FreeBSD Foundation,
is that for a complete newcomer to FreeBSD, it is very difficult for a
newcomer to
navigate all our web pages and wikis, and figure out where they can jump in
and contribute
to the project.

The FreeBSD project could definitely work to improve this area,
in order to attract new blood and new ideas to the project.  Streamlining
the ideas
page would be a good start.

--
Craig
___
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: Instant panic while trying run ports-mgmt/poudriere

[Lawrence Stewart]

On 08/27/15 17:15, Don Lewis wrote:
 On 27 Aug, Don Lewis wrote:
 On 27 Aug, Lawrence Stewart wrote:
 On 08/27/15 09:36, John-Mark Gurney wrote:
 Andriy Gapon wrote this message on Sun, Aug 23, 2015 at 09:54 +0300:
 On 12/08/2015 17:11, Lawrence Stewart wrote:
 On 08/07/15 07:33, Pawel Pekala wrote:
 Hi K.,

 On 2015-08-06 12:33 -0700, K. Macy km...@freebsd.org wrote:
 Is this still happening?

 Still crashes:

 +1 for me running r286617

 Here is another +1 with r286922.
 I can add a couple of bits of debugging data:

 (kgdb) fr 8
 #8  0x80639d60 in knote (list=0xf8019a733ea0,
 hint=2147483648, lockflags=value optimized out) at
 /usr/src/sys/kern/kern_event.c:1964
 1964} else if ((lockflags  KNF_NOKQLOCK) != 0) {
 (kgdb) p *list
 $2 = {kl_list = {slh_first = 0x0}, kl_lock = 0x8063a1e0

 We should/cannot get here w/ an empty list.  If we do, then there is
 something seriously wrong...  The current kn (which we must have as we
 are here) MUST be on the list, but as you just showed, there are no
 knotes on the list.

 Can you get me a print of the knote?  That way I can see what flags
 are on it?

 I quickly tried to get this info for you by building my kernel with -O0
 and reproducing, but I get an insta-panic on boot with the new kernel:

 Fatal double fault
 rip = 0x8218c794
 rsp = 0xfe044cdc9fe0
 rbp = 0xfe044cdca110
 cpuid = 2; apic id = 02
 panic: double fault
 cpuid = 2
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
 0xfe03dcfffe30
 vpanic() at vpanic+0x189/frame 0xfe03dcfffeb0
 panic() at panic+0x43/frame 0xfe03dc10
 dblfault_handler() at dblfault_handler+0xa2/frame 0xfe03dc30
 Xdblfault() at Xdblfault+0xac/frame 0xfe03dc30
 --- trap 0x17, rip = 0x8218c794, rsp = 0xfe044cdc9fe0, rbp =
 0xfe044cdca110 ---
 vdev_queue_aggregate() at vdev_queue_aggregate+0x34/frame 0xfe044cdca110
 vdev_queue_io_to_issue() at vdev_queue_io_to_issue+0x1f5/frame
 0xfe044cdca560
 vdev_queue_io() at vdev_queue_io+0x19a/frame 0xfe044cdca5b0
 zio_vdev_io_start() at zio_vdev_io_start+0x81f/frame 0xfe044cdca6e0
 zio_execute() at zio_execute+0x23b/frame 0xfe044cdca730
 zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca760
 vdev_mirror_io_start() at vdev_mirror_io_start+0x140/frame
 0xfe044cdca800
 zio_vdev_io_start() at zio_vdev_io_start+0x12f/frame 0xfe044cdca930
 zio_execute() at zio_execute+0x23b/frame 0xfe044cdca980
 zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca9b0
 spa_load_verify_cb() at spa_load_verify_cb+0x37d/frame 0xfe044cdcaa50
 traverse_visitbp() at traverse_visitbp+0x5a5/frame 0xfe044cdcac60
 traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcacd0
 traverse_visitbp() at traverse_visitbp+0xc66/frame 0xfe044cdcaee0
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb0f0
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb300
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb510
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb720
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb930
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcbb40
 traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcbbb0
 traverse_visitbp() at traverse_visitbp+0xe59/frame 0xfe044cdcbdc0
 traverse_impl() at traverse_impl+0x79d/frame 0xfe044cdcbfd0
 traverse_dataset() at traverse_dataset+0x93/frame 0xfe044cdcc040
 traverse_pool() at traverse_pool+0x1f2/frame 0xfe044cdcc140
 spa_load_verify() at spa_load_verify+0xf3/frame 0xfe044cdcc1f0
 spa_load_impl() at spa_load_impl+0x2069/frame 0xfe044cdcc610
 spa_load() at spa_load+0x320/frame 0xfe044cdcc6d0
 spa_load_impl() at spa_load_impl+0x150b/frame 0xfe044cdccaf0
 spa_load() at spa_load+0x320/frame 0xfe044cdccbb0
 spa_load_best() at spa_load_best+0xc6/frame 0xfe044cdccc50
 spa_open_common() at spa_open_common+0x246/frame 0xfe044cdccd40
 spa_open() at spa_open+0x35/frame 0xfe044cdccd70
 dsl_pool_hold() at dsl_pool_hold+0x2d/frame 0xfe044cdccdb0
 dmu_objset_own() at dmu_objset_own+0x2e/frame 0xfe044cdcce30
 zfsvfs_create() at zfsvfs_create+0x100/frame 0xfe044cdcd050
 zfs_domount() at zfs_domount+0xa7/frame 0xfe044cdcd0e0
 zfs_mount() at zfs_mount+0x6c3/frame 0xfe044cdcd390
 vfs_donmount() at vfs_donmount+0x1330/frame 0xfe044cdcd660
 kernel_mount() at kernel_mount+0x62/frame 0xfe044cdcd6c0
 parse_mount() at parse_mount+0x668/frame 0xfe044cdcd810
 vfs_mountroot() at vfs_mountroot+0x85c/frame 0xfe044cdcd9d0
 start_init() at start_init+0x62/frame 0xfe044cdcda70
 fork_exit() at fork_exit+0x84/frame 0xfe044cdcdab0
 fork_trampoline() at fork_trampoline+0xe/frame 0xfe044cdcdab0
 --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
 KDB: enter: panic

 Didn't get a core because it panics before dumpdev is set.

 Is anyone 

Re: Why does netstat not work in jails?

[Allan Jude]

On 2015-08-27 22:12, Julian Elischer wrote:
 On 8/28/15 9:54 AM, Chris H wrote:
 I've been attempting to run jails on an 11-CURRENT
 for the purpose of building world/kernel  ports
 for all of our 9-STABLE production servers. I'm using
 standard/classic jail setup(s) -- not using any
 of the convenience ports/applications that abstract
 the process in any way.
 While everything seemed to go as intended/anticipated,
 I'm seeing things I *didn't* expect.
 The host network get's it's public IP from the router
 in front of it. From the router, I insure that it is
 allocated the same non-public IP everytime. So DHCP
 assigns it 192.168.0.100. I assigned the jail 192.168.0.103.
 SSHD is started within the jail, root IS allowed login.
 But any attempt to ssh to 192.168.0.103 from the host,
 returns:
 ssh_exchange_identification: Connection closed by remote host.

 SSHD id NOT running on the host.

 inetd_flags=-wW -a 192.168.0.100 and syslogd_flags=-ss
 is set on the host via rc.conf
 what does netstat -aAn show (on the main host).
 
 second issue; loging into the jail, via jexex. If I perform:
 netstat -nr
 The following is returned:
 netstat: kvm not available: /dev/mem: No such file or directory
 is there a /dev in the jail?  if you have set it up, have you allowed
 mem to be one of the exported devices?
 I forget the exact details on how to set this but hopefully it's a hint.
 I have to look it up every time.
 
 Routing tables
 rt_tables: symbol not in namelist

 Any thought's jump out at anyone?

 Thanks!

 --Chris

 -- 

Normally I wouldn't think you would want /dev/mem to be accessible
inside a jail, but you can probably do it by editing some of the devfs
rules.

What info are you trying to get from netstat? some of the info is
available from sockstat etc.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

FreeBSD_HEAD - Build #3138 - Failure

[jenkins-admin]

FreeBSD_HEAD - Build #3138 - Failure:

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

Change summaries:

287240 by jhibbits:
Extend pmap to support e500mc and e5500.

As part of this, clean up tlb1_init(), since bootinfo is always NULL here just
eliminate the loop altogether.

Also, fix a bug in mmu_booke_mapdev_attr() where it's possible to map a larger
immediately following a smaller page, causing the mappings to overlap.  Instead,
break up the new mapping into smaller chunks.  The downside to this is that it
uses more precious TLB1 entries, which, on smaller chips (e500v2) it could cause
problems with TLB1 being out of space (e500v2 only has 16 TLB1 entries).

Obtained from:  Semihalf (partial)
Sponsored by:   Alex Perez/Inertial Computing

287239 by imp:
Simply to appease gcc's warnings.

287238 by yongari:
Set DMA alignment constraint of status, TX and RX LEs(List Elements
in Marvell terms) to 32768.  32768 looks overkill but it will
ensure correct DMAed update.  This change addresses occasional
watchdog timeouts reported on 10.2-RELEASE.

Tested by:  Johann Hugo jh...@meraka.csir.co.za
MFC after:  2 weeks

287237 by delphij:
Respect locale settings.

MFC after:  2 weeks

287236 by delphij:
Use exit() instead of return in main().

MFC after:  2 weeks

287235 by markj:
Remove weighted page handling from vm_page_advise().

This was added in r51337 as part of the implementation of
madvise(MADV_DONTNEED).  Its objective was to ensure that the page daemon
would eventually reclaim other unreferenced pages (i.e., unreferenced pages
not touched by madvise()) from the active queue.

Now that the pagedaemon performs steady scanning of the active page queue,
this weighted handling is unnecessary.  Instead, always cache clean pages
by moving them to the head of the inactive page queue.  This simplifies the
implementation of vm_page_advise() and eliminates the fragmentation that
resulted from the distribution of pages among multiple queues.

Suggested by:   alc
Reviewed by:alc
Sponsored by:   EMC / Isilon Storage Division
Differential Revision:  https://reviews.freebsd.org/D3401

287234 by markj:
Re-apply r274569. It was reverted in r276848 since that appeared to fix
some ctfmerge crashes that started to occur on i386 weeks after r274569 was
committed. Some later investigation indicated that the crashes were caused
by malformed CTF info that led to a stack overflow. The issue with CTF
info in i386 kernels seems to have been resolved by r261246, which updated
libdwarf and libelf.

r274569 fixes a bug which caused duplicate types to appear in the kernel's
CTF info. This duplication generally does not cause problems when using
DTrace, but makes it easier to hit the limit of 2^15 - 1 distinct type
definitions in a CTF container.

MFC after:  2 weeks

287233 by markj:
Remove an unneeded instruction.

MFC after:  1 week

287232 by markj:
nv.h lives in sys/ as of r279439.

287227 by imp:
Use CFLAGS_NO_SIMD in preference to varying lists of -mno- flags.
Go ahead and defined -D_STANDALONE for all targets (only strictly
needed for some architecture, but harmless on those it isn't required
for). Also add -msoft-float to all architectures uniformly rather
that higgley piggley like it is today.

Differential Revision: https://reviews.freebsd.org/D3496

287225 by imp:
New 1-Wire bus implementation. 1-Wire controller is abstracted, though
only gpiobus configured via FDT is supported. Bus enumeration is
supported. Devices are created for each device found. 1-Wire
temperature controllers are supported, but other drivers could be
written. Temperatures are polled and reported via a sysctl.  Errors
are reported via sysctl counters. Mis-wired bus detection is included
for more trouble shooting. See ow(4), owc(4) and ow_temp(4) for
details of what's supported and known issues.

This has been tested on Raspberry Pi-B, Pi2 and Beagle Bone Black
with up to 7 devices.

Differential Revision: https://reviews.freebsd.org/D2956
Relnotes: yes
MFC after: 2 weeks
Reviewed by: loos@ (with many insightful comments)



The end of the build log:

[...truncated 55574 lines...]
--- DiagnosticFrontendKinds.inc.h ---
clang-tblgen -gen-clang-diags-defs -clang-component=Frontend  -I 
/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic
 -d DiagnosticFrontendKinds.inc.d  -o DiagnosticFrontendKinds.inc.h 
/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
--- DiagnosticLexKinds.inc.h ---
clang-tblgen -gen-clang-diags-defs -clang-component=Lex  -I 
/builds/FreeBSD_HEAD/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic
 -d DiagnosticLexKinds.inc.d  -o DiagnosticLexKinds.inc.h 

Re: Instant panic while trying run ports-mgmt/poudriere

[Lawrence Stewart]

On 08/23/15 22:54, Konstantin Belousov wrote:
 On Sun, Aug 23, 2015 at 12:08:16PM +0300, Konstantin Belousov wrote:
 On Sun, Aug 23, 2015 at 09:54:28AM +0300, Andriy Gapon wrote:
 On 12/08/2015 17:11, Lawrence Stewart wrote:
 On 08/07/15 07:33, Pawel Pekala wrote:
 Hi K.,

 On 2015-08-06 12:33 -0700, K. Macy km...@freebsd.org wrote:
 Is this still happening?

 Still crashes:

 +1 for me running r286617

 Here is another +1 with r286922.
 I can add a couple of bits of debugging data:

 (kgdb) fr 8
 #8  0x80639d60 in knote (list=0xf8019a733ea0,
 hint=2147483648, lockflags=value optimized out) at
 /usr/src/sys/kern/kern_event.c:1964
 1964} else if ((lockflags  KNF_NOKQLOCK) != 0) {
 (kgdb) p *list
 $2 = {kl_list = {slh_first = 0x0}, kl_lock = 0x8063a1e0
 knlist_mtx_lock, kl_unlock = 0x8063a200 knlist_mtx_unlock,
   kl_assert_locked = 0x8063a220 knlist_mtx_assert_locked,
 kl_assert_unlocked = 0x8063a240 knlist_mtx_assert_unlocked,
   kl_lockarg = 0xf8019a733bb0}
 (kgdb) disassemble
 Dump of assembler code for function knote:
 0x80639d00 knote+0:   push   %rbp
 0x80639d01 knote+1:   mov%rsp,%rbp
 0x80639d04 knote+4:   push   %r15
 0x80639d06 knote+6:   push   %r14
 0x80639d08 knote+8:   push   %r13
 0x80639d0a knote+10:  push   %r12
 0x80639d0c knote+12:  push   %rbx
 0x80639d0d knote+13:  sub$0x18,%rsp
 0x80639d11 knote+17:  mov%edx,%r12d
 0x80639d14 knote+20:  mov%rsi,-0x30(%rbp)
 0x80639d18 knote+24:  mov%rdi,%rbx
 0x80639d1b knote+27:  test   %rbx,%rbx
 0x80639d1e knote+30:  je 0x80639ef6 knote+502
 0x80639d24 knote+36:  mov%r12d,%eax
 0x80639d27 knote+39:  and$0x1,%eax
 0x80639d2a knote+42:  mov%eax,-0x3c(%rbp)
 0x80639d2d knote+45:  mov0x28(%rbx),%rdi
 0x80639d31 knote+49:  je 0x80639d38 knote+56
 0x80639d33 knote+51:  callq  *0x18(%rbx)
 0x80639d36 knote+54:  jmp0x80639d42 knote+66
 0x80639d38 knote+56:  callq  *0x20(%rbx)
 0x80639d3b knote+59:  mov0x28(%rbx),%rdi
 0x80639d3f knote+63:  callq  *0x8(%rbx)
 0x80639d42 knote+66:  mov%rbx,-0x38(%rbp)
 0x80639d46 knote+70:  mov(%rbx),%rbx
 0x80639d49 knote+73:  test   %rbx,%rbx
 0x80639d4c knote+76:  je 0x80639ee5 knote+485
 0x80639d52 knote+82:  and$0x2,%r12d
 0x80639d56 knote+86:  nopw   %cs:0x0(%rax,%rax,1)
 0x80639d60 knote+96:  mov0x28(%rbx),%r14

 Panic is in the last quoted instruction.
 And:
 (kgdb) i reg
 rax0x246582
 rbx0xdeadc0dedeadc0de   -2401050962867404578
 rcx0x0  0
 rdx0x12e302
 rsi0x80a26a5a   -2136839590
 rdi0x80e81b80   -2132272256
 rbp0xfe02b7efea20   0xfe02b7efea20
 rsp0xfe02b7efe9e0   0xfe02b7efe9e0
 r8 0x80a269ce   -2136839730
 r9 0x80e82838   -2132269000
 r100x1  65536
 r110x80fabd10   -2131051248
 r120x0  0
 r130xf801ff84a818   -8787511171048
 r140xf801ff84a800   -8787511171072
 r150xf8019a6974f0   -8789207452432
 rip0x80639d60   0x80639d60 knote+96
 eflags 0x10286  66182

 I think that $rbx stands out here (this is a kernel with INVARIANTS).

 Looking at the code, is it possible that one of the calls from within
 the loop's body modifies the list?  If that is so and provided that is a
 valid behavior, then maybe using SLIST_FOREACH_SAFE would help.

 This is first time a useful debugging data was posted.

 The 0x28 offset may indicate either kn_kq member access of the struct
 knote, or kq_list of the struct kqueue.

 kl_list.slh_first of the list parameter is NULL, how would a list
 iteration loop even start ?  Can you look up the list argument value
 from the previous frame (%rdi is overwritten, so debugger might be
 confused) ?
 
 After looking at your data closely, I think you are right.  The panic
 occurs when the exit1(9) does KNOTE_LOCKED(NOTE_EXIT).  This is the
 only case in the tree where filter uses knlist_remove_inevent() to detach
 processed note, so indeed the slist is modified under the iterator.
 
 Below is the patch with the suggested change and unrelated cleanup of
 the uma(9) KPI use.  Please test, everybody who has a panic with the
 backtrace pointing to the sys_exit().

Fixes the panic for me too, thanks Kostik.

Cheers,
Lawrence
___
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: Why does netstat not work in jails?

[Alexander V . Chernikov]

28.08.2015, 04:56, Chris H bsd-li...@bsdforge.com:
 I've been attempting to run jails on an 11-CURRENT
 for the purpose of building world/kernel  ports
 for all of our 9-STABLE production servers. I'm using
 standard/classic jail setup(s) -- not using any
 of the convenience ports/applications that abstract
 the process in any way.
 While everything seemed to go as intended/anticipated,
 I'm seeing things I *didn't* expect.
 The host network get's it's public IP from the router
 in front of it. From the router, I insure that it is
 allocated the same non-public IP everytime. So DHCP
 assigns it 192.168.0.100. I assigned the jail 192.168.0.103.
 SSHD is started within the jail, root IS allowed login.
 But any attempt to ssh to 192.168.0.103 from the host,
 returns:
 ssh_exchange_identification: Connection closed by remote host.

 SSHD id NOT running on the host.

 inetd_flags=-wW -a 192.168.0.100 and syslogd_flags=-ss
 is set on the host via rc.conf

 second issue; loging into the jail, via jexex. If I perform:
 netstat -nr
 The following is returned:
 netstat: kvm not available: /dev/mem: No such file or directory
 Routing tables
 rt_tables: symbol not in namelist

 Any thought's jump out at anyone?
Direct kvm interface was removed from head a year ago.
What you can do is recompiling netstat binary from 9 with NewTree variable 
defined to 1 and see if this helps.
Output will look  a bit different, but you'll be able to see routing tables 
from jail.
https://svnweb.freebsd.org/base/stable/9/usr.bin/netstat/route.c?revision=242025view=markup#l122

Another option is merging r261207 and r263335.


 Thanks!

 --Chris

 --

 ___
 freebsd-current@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Why does netstat not work in jails?

[Julian Elischer]

On 8/28/15 9:54 AM, Chris H wrote:

I've been attempting to run jails on an 11-CURRENT
for the purpose of building world/kernel  ports
for all of our 9-STABLE production servers. I'm using
standard/classic jail setup(s) -- not using any
of the convenience ports/applications that abstract
the process in any way.
While everything seemed to go as intended/anticipated,
I'm seeing things I *didn't* expect.
The host network get's it's public IP from the router
in front of it. From the router, I insure that it is
allocated the same non-public IP everytime. So DHCP
assigns it 192.168.0.100. I assigned the jail 192.168.0.103.
SSHD is started within the jail, root IS allowed login.
But any attempt to ssh to 192.168.0.103 from the host,
returns:
ssh_exchange_identification: Connection closed by remote host.

SSHD id NOT running on the host.

inetd_flags=-wW -a 192.168.0.100 and syslogd_flags=-ss
is set on the host via rc.conf

what does netstat -aAn show (on the main host).


second issue; loging into the jail, via jexex. If I perform:
netstat -nr
The following is returned:
netstat: kvm not available: /dev/mem: No such file or directory
is there a /dev in the jail?  if you have set it up, have you allowed 
mem to be one of the exported devices?
I forget the exact details on how to set this but hopefully it's a 
hint. I have to look it up every time.



Routing tables
rt_tables: symbol not in namelist

Any thought's jump out at anyone?

Thanks!

--Chris

--


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Why does netstat not work in jails?

[Chris H]

On Thu, 27 Aug 2015 22:33:04 -0400 Allan Jude allanj...@freebsd.org wrote

 On 2015-08-27 22:12, Julian Elischer wrote:
  On 8/28/15 9:54 AM, Chris H wrote:
  I've been attempting to run jails on an 11-CURRENT
  for the purpose of building world/kernel  ports
  for all of our 9-STABLE production servers. I'm using
  standard/classic jail setup(s) -- not using any
  of the convenience ports/applications that abstract
  the process in any way.
  While everything seemed to go as intended/anticipated,
  I'm seeing things I *didn't* expect.
  The host network get's it's public IP from the router
  in front of it. From the router, I insure that it is
  allocated the same non-public IP everytime. So DHCP
  assigns it 192.168.0.100. I assigned the jail 192.168.0.103.
  SSHD is started within the jail, root IS allowed login.
  But any attempt to ssh to 192.168.0.103 from the host,
  returns:
  ssh_exchange_identification: Connection closed by remote host.
 
  SSHD id NOT running on the host.
 
  inetd_flags=-wW -a 192.168.0.100 and syslogd_flags=-ss
  is set on the host via rc.conf
  what does netstat -aAn show (on the main host).
  
  second issue; loging into the jail, via jexex. If I perform:
  netstat -nr
  The following is returned:
  netstat: kvm not available: /dev/mem: No such file or directory
  is there a /dev in the jail?  if you have set it up, have you allowed
  mem to be one of the exported devices?
  I forget the exact details on how to set this but hopefully it's a hint.
  I have to look it up every time.

Thanks for the hint, Julian!
  
  Routing tables
  rt_tables: symbol not in namelist
 
  Any thought's jump out at anyone?
 
  Thanks!
 
  --Chris
 
  -- 
 
 Normally I wouldn't think you would want /dev/mem to be accessible
 inside a jail, but you can probably do it by editing some of the devfs
 rules.
 
 What info are you trying to get from netstat?
Get some idea of what the jail thinks it's [network] topology is.
So I might better debug my being unable to ssh into it from the
host.

 some of the info is available from sockstat etc.
Indeed, sockstat(1) surprisingly *does* work. I thought of using it,
too. But assumed /dev/mem would have been involved there, also.
 
 -- 
 Allan Jude

Thanks, Allen, Julian!

--Chris


___
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_HEAD - Build #3133 - Failure

[jenkins-admin]

FreeBSD_HEAD - Build #3133 - Failure:

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

Change summaries:

287196 by jch:
In callout_stop(), if a callout is both pending and currently
being serviced return 0 (fail) but it is applicable only
mpsafe callouts.  Thanks to hselasky for finding this.

Differential Revision:  https://reviews.freebsd.org/D3078 (Updated)
Submitted by:   hselasky
Reviewed by:jch

287195 by melifaro:
Fix packets/bytes accounting on i386.

Spotted by: julian

287193 by delphij:
Plug a possible memory leak.

MFC after:  2 weeks

287192 by bapt:
More fixes to the new macros

287191 by bapt:
Fix typo in new macros



The end of the build log:

[...truncated 283978 lines...]
--- rt2860.o ---
cc  -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I. 
-I/builds/FreeBSD_HEAD/sys -I/builds/FreeBSD_HEAD/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse 
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  
-Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign  -mno-aes -mno-avx  -std=iso9899:1999 -Werror  
/builds/FreeBSD_HEAD/sys/dev/ral/rt2860.c
--- rt2560.o ---
ctfconvert -L VERSION -g rt2560.o
--- randomdev.o ---
cc  -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I. 
-I/builds/FreeBSD_HEAD/sys -I/builds/FreeBSD_HEAD/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse 
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  
-Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign  -mno-aes -mno-avx  -std=iso9899:1999 -Werror  
/builds/FreeBSD_HEAD/sys/dev/random/randomdev.c
--- if_mwl.o ---
ctfconvert -L VERSION -g if_mwl.o
--- syscons.o ---
cc  -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I. 
-I/builds/FreeBSD_HEAD/sys -I/builds/FreeBSD_HEAD/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse 
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  
-Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign  -mno-aes -mno-avx  -std=iso9899:1999 -Werror  
/builds/FreeBSD_HEAD/sys/dev/syscons/syscons.c
--- rt2661.o ---
ctfconvert -L VERSION -g rt2661.o
--- uart_dbg.o ---
cc  -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I. 
-I/builds/FreeBSD_HEAD/sys -I/builds/FreeBSD_HEAD/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse 
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  
-Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign  -mno-aes -mno-avx  -std=iso9899:1999 -Werror  
/builds/FreeBSD_HEAD/sys/dev/uart/uart_dbg.c
--- randomdev.o ---
ctfconvert -L VERSION -g randomdev.o
--- uart_subr.o ---
cc  -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I. 
-I/builds/FreeBSD_HEAD/sys -I/builds/FreeBSD_HEAD/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -mcmodel=kernel 

Re: Instant panic while trying run ports-mgmt/poudriere

[Lawrence Stewart]

On 08/27/15 09:36, John-Mark Gurney wrote:
 Andriy Gapon wrote this message on Sun, Aug 23, 2015 at 09:54 +0300:
 On 12/08/2015 17:11, Lawrence Stewart wrote:
 On 08/07/15 07:33, Pawel Pekala wrote:
 Hi K.,

 On 2015-08-06 12:33 -0700, K. Macy km...@freebsd.org wrote:
 Is this still happening?

 Still crashes:

 +1 for me running r286617

 Here is another +1 with r286922.
 I can add a couple of bits of debugging data:

 (kgdb) fr 8
 #8  0x80639d60 in knote (list=0xf8019a733ea0,
 hint=2147483648, lockflags=value optimized out) at
 /usr/src/sys/kern/kern_event.c:1964
 1964} else if ((lockflags  KNF_NOKQLOCK) != 0) {
 (kgdb) p *list
 $2 = {kl_list = {slh_first = 0x0}, kl_lock = 0x8063a1e0
 
 We should/cannot get here w/ an empty list.  If we do, then there is
 something seriously wrong...  The current kn (which we must have as we
 are here) MUST be on the list, but as you just showed, there are no
 knotes on the list.
 
 Can you get me a print of the knote?  That way I can see what flags
 are on it?

I quickly tried to get this info for you by building my kernel with -O0
and reproducing, but I get an insta-panic on boot with the new kernel:

Fatal double fault
rip = 0x8218c794
rsp = 0xfe044cdc9fe0
rbp = 0xfe044cdca110
cpuid = 2; apic id = 02
panic: double fault
cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe03dcfffe30
vpanic() at vpanic+0x189/frame 0xfe03dcfffeb0
panic() at panic+0x43/frame 0xfe03dc10
dblfault_handler() at dblfault_handler+0xa2/frame 0xfe03dc30
Xdblfault() at Xdblfault+0xac/frame 0xfe03dc30
--- trap 0x17, rip = 0x8218c794, rsp = 0xfe044cdc9fe0, rbp =
0xfe044cdca110 ---
vdev_queue_aggregate() at vdev_queue_aggregate+0x34/frame 0xfe044cdca110
vdev_queue_io_to_issue() at vdev_queue_io_to_issue+0x1f5/frame
0xfe044cdca560
vdev_queue_io() at vdev_queue_io+0x19a/frame 0xfe044cdca5b0
zio_vdev_io_start() at zio_vdev_io_start+0x81f/frame 0xfe044cdca6e0
zio_execute() at zio_execute+0x23b/frame 0xfe044cdca730
zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca760
vdev_mirror_io_start() at vdev_mirror_io_start+0x140/frame
0xfe044cdca800
zio_vdev_io_start() at zio_vdev_io_start+0x12f/frame 0xfe044cdca930
zio_execute() at zio_execute+0x23b/frame 0xfe044cdca980
zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca9b0
spa_load_verify_cb() at spa_load_verify_cb+0x37d/frame 0xfe044cdcaa50
traverse_visitbp() at traverse_visitbp+0x5a5/frame 0xfe044cdcac60
traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcacd0
traverse_visitbp() at traverse_visitbp+0xc66/frame 0xfe044cdcaee0
traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb0f0
traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb300
traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb510
traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb720
traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb930
traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcbb40
traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcbbb0
traverse_visitbp() at traverse_visitbp+0xe59/frame 0xfe044cdcbdc0
traverse_impl() at traverse_impl+0x79d/frame 0xfe044cdcbfd0
traverse_dataset() at traverse_dataset+0x93/frame 0xfe044cdcc040
traverse_pool() at traverse_pool+0x1f2/frame 0xfe044cdcc140
spa_load_verify() at spa_load_verify+0xf3/frame 0xfe044cdcc1f0
spa_load_impl() at spa_load_impl+0x2069/frame 0xfe044cdcc610
spa_load() at spa_load+0x320/frame 0xfe044cdcc6d0
spa_load_impl() at spa_load_impl+0x150b/frame 0xfe044cdccaf0
spa_load() at spa_load+0x320/frame 0xfe044cdccbb0
spa_load_best() at spa_load_best+0xc6/frame 0xfe044cdccc50
spa_open_common() at spa_open_common+0x246/frame 0xfe044cdccd40
spa_open() at spa_open+0x35/frame 0xfe044cdccd70
dsl_pool_hold() at dsl_pool_hold+0x2d/frame 0xfe044cdccdb0
dmu_objset_own() at dmu_objset_own+0x2e/frame 0xfe044cdcce30
zfsvfs_create() at zfsvfs_create+0x100/frame 0xfe044cdcd050
zfs_domount() at zfs_domount+0xa7/frame 0xfe044cdcd0e0
zfs_mount() at zfs_mount+0x6c3/frame 0xfe044cdcd390
vfs_donmount() at vfs_donmount+0x1330/frame 0xfe044cdcd660
kernel_mount() at kernel_mount+0x62/frame 0xfe044cdcd6c0
parse_mount() at parse_mount+0x668/frame 0xfe044cdcd810
vfs_mountroot() at vfs_mountroot+0x85c/frame 0xfe044cdcd9d0
start_init() at start_init+0x62/frame 0xfe044cdcda70
fork_exit() at fork_exit+0x84/frame 0xfe044cdcdab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe044cdcdab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

Didn't get a core because it panics before dumpdev is set.

Is anyone else able to run -O0 kernels or do I have something set to evil?

Cheers,
Lawrence
___
freebsd-current@freebsd.org mailing list

FreeBSD_HEAD - Build #3132 - Fixed

[jenkins-admin]

FreeBSD_HEAD - Build #3132 - Fixed:

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

Change summaries:

287190 by marcel:
An error of -1 from parse_mount() indicates that the specification
was invalid. Don't trigger a mount failure (which by default means
a panic), but instead just move on to the next directive in the
configuration. This typically has us ask for the root mount.

PR: 163245

287189 by jhibbits:
Fix freescale sdhc driver, and add it to the files list.

Also, add it to the mmc DRIVER_MODULE attachment list.

287188 by jhibbits:
Use the macro definition for EXC_PGM_TRAP, instead of the magic number.

287187 by imp:
Make sys.mk more compatible with fmake by refraining from using :U
modifiers.

Differential Revision: https://reviews.freebsd.org/D3228

___
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: Instant panic while trying run ports-mgmt/poudriere

[Don Lewis]

On 27 Aug, Lawrence Stewart wrote:
 On 08/27/15 09:36, John-Mark Gurney wrote:
 Andriy Gapon wrote this message on Sun, Aug 23, 2015 at 09:54 +0300:
 On 12/08/2015 17:11, Lawrence Stewart wrote:
 On 08/07/15 07:33, Pawel Pekala wrote:
 Hi K.,

 On 2015-08-06 12:33 -0700, K. Macy km...@freebsd.org wrote:
 Is this still happening?

 Still crashes:

 +1 for me running r286617

 Here is another +1 with r286922.
 I can add a couple of bits of debugging data:

 (kgdb) fr 8
 #8  0x80639d60 in knote (list=0xf8019a733ea0,
 hint=2147483648, lockflags=value optimized out) at
 /usr/src/sys/kern/kern_event.c:1964
 1964} else if ((lockflags  KNF_NOKQLOCK) != 0) {
 (kgdb) p *list
 $2 = {kl_list = {slh_first = 0x0}, kl_lock = 0x8063a1e0
 
 We should/cannot get here w/ an empty list.  If we do, then there is
 something seriously wrong...  The current kn (which we must have as we
 are here) MUST be on the list, but as you just showed, there are no
 knotes on the list.
 
 Can you get me a print of the knote?  That way I can see what flags
 are on it?
 
 I quickly tried to get this info for you by building my kernel with -O0
 and reproducing, but I get an insta-panic on boot with the new kernel:
 
 Fatal double fault
 rip = 0x8218c794
 rsp = 0xfe044cdc9fe0
 rbp = 0xfe044cdca110
 cpuid = 2; apic id = 02
 panic: double fault
 cpuid = 2
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
 0xfe03dcfffe30
 vpanic() at vpanic+0x189/frame 0xfe03dcfffeb0
 panic() at panic+0x43/frame 0xfe03dc10
 dblfault_handler() at dblfault_handler+0xa2/frame 0xfe03dc30
 Xdblfault() at Xdblfault+0xac/frame 0xfe03dc30
 --- trap 0x17, rip = 0x8218c794, rsp = 0xfe044cdc9fe0, rbp =
 0xfe044cdca110 ---
 vdev_queue_aggregate() at vdev_queue_aggregate+0x34/frame 0xfe044cdca110
 vdev_queue_io_to_issue() at vdev_queue_io_to_issue+0x1f5/frame
 0xfe044cdca560
 vdev_queue_io() at vdev_queue_io+0x19a/frame 0xfe044cdca5b0
 zio_vdev_io_start() at zio_vdev_io_start+0x81f/frame 0xfe044cdca6e0
 zio_execute() at zio_execute+0x23b/frame 0xfe044cdca730
 zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca760
 vdev_mirror_io_start() at vdev_mirror_io_start+0x140/frame
 0xfe044cdca800
 zio_vdev_io_start() at zio_vdev_io_start+0x12f/frame 0xfe044cdca930
 zio_execute() at zio_execute+0x23b/frame 0xfe044cdca980
 zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca9b0
 spa_load_verify_cb() at spa_load_verify_cb+0x37d/frame 0xfe044cdcaa50
 traverse_visitbp() at traverse_visitbp+0x5a5/frame 0xfe044cdcac60
 traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcacd0
 traverse_visitbp() at traverse_visitbp+0xc66/frame 0xfe044cdcaee0
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb0f0
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb300
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb510
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb720
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb930
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcbb40
 traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcbbb0
 traverse_visitbp() at traverse_visitbp+0xe59/frame 0xfe044cdcbdc0
 traverse_impl() at traverse_impl+0x79d/frame 0xfe044cdcbfd0
 traverse_dataset() at traverse_dataset+0x93/frame 0xfe044cdcc040
 traverse_pool() at traverse_pool+0x1f2/frame 0xfe044cdcc140
 spa_load_verify() at spa_load_verify+0xf3/frame 0xfe044cdcc1f0
 spa_load_impl() at spa_load_impl+0x2069/frame 0xfe044cdcc610
 spa_load() at spa_load+0x320/frame 0xfe044cdcc6d0
 spa_load_impl() at spa_load_impl+0x150b/frame 0xfe044cdccaf0
 spa_load() at spa_load+0x320/frame 0xfe044cdccbb0
 spa_load_best() at spa_load_best+0xc6/frame 0xfe044cdccc50
 spa_open_common() at spa_open_common+0x246/frame 0xfe044cdccd40
 spa_open() at spa_open+0x35/frame 0xfe044cdccd70
 dsl_pool_hold() at dsl_pool_hold+0x2d/frame 0xfe044cdccdb0
 dmu_objset_own() at dmu_objset_own+0x2e/frame 0xfe044cdcce30
 zfsvfs_create() at zfsvfs_create+0x100/frame 0xfe044cdcd050
 zfs_domount() at zfs_domount+0xa7/frame 0xfe044cdcd0e0
 zfs_mount() at zfs_mount+0x6c3/frame 0xfe044cdcd390
 vfs_donmount() at vfs_donmount+0x1330/frame 0xfe044cdcd660
 kernel_mount() at kernel_mount+0x62/frame 0xfe044cdcd6c0
 parse_mount() at parse_mount+0x668/frame 0xfe044cdcd810
 vfs_mountroot() at vfs_mountroot+0x85c/frame 0xfe044cdcd9d0
 start_init() at start_init+0x62/frame 0xfe044cdcda70
 fork_exit() at fork_exit+0x84/frame 0xfe044cdcdab0
 fork_trampoline() at fork_trampoline+0xe/frame 0xfe044cdcdab0
 --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
 KDB: enter: panic
 
 Didn't get a core because it panics before dumpdev is set.
 
 Is anyone else able to run -O0 kernels or do I have something set to 

Is NextBSD safe for bhyve?

[Russell Haley]

Is NextBSD safe for bhyve?

Thanks

Russ
___
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: Instant panic while trying run ports-mgmt/poudriere

[Don Lewis]

On 27 Aug, Don Lewis wrote:
 On 27 Aug, Lawrence Stewart wrote:
 On 08/27/15 09:36, John-Mark Gurney wrote:
 Andriy Gapon wrote this message on Sun, Aug 23, 2015 at 09:54 +0300:
 On 12/08/2015 17:11, Lawrence Stewart wrote:
 On 08/07/15 07:33, Pawel Pekala wrote:
 Hi K.,

 On 2015-08-06 12:33 -0700, K. Macy km...@freebsd.org wrote:
 Is this still happening?

 Still crashes:

 +1 for me running r286617

 Here is another +1 with r286922.
 I can add a couple of bits of debugging data:

 (kgdb) fr 8
 #8  0x80639d60 in knote (list=0xf8019a733ea0,
 hint=2147483648, lockflags=value optimized out) at
 /usr/src/sys/kern/kern_event.c:1964
 1964} else if ((lockflags  KNF_NOKQLOCK) != 0) {
 (kgdb) p *list
 $2 = {kl_list = {slh_first = 0x0}, kl_lock = 0x8063a1e0
 
 We should/cannot get here w/ an empty list.  If we do, then there is
 something seriously wrong...  The current kn (which we must have as we
 are here) MUST be on the list, but as you just showed, there are no
 knotes on the list.
 
 Can you get me a print of the knote?  That way I can see what flags
 are on it?
 
 I quickly tried to get this info for you by building my kernel with -O0
 and reproducing, but I get an insta-panic on boot with the new kernel:
 
 Fatal double fault
 rip = 0x8218c794
 rsp = 0xfe044cdc9fe0
 rbp = 0xfe044cdca110
 cpuid = 2; apic id = 02
 panic: double fault
 cpuid = 2
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
 0xfe03dcfffe30
 vpanic() at vpanic+0x189/frame 0xfe03dcfffeb0
 panic() at panic+0x43/frame 0xfe03dc10
 dblfault_handler() at dblfault_handler+0xa2/frame 0xfe03dc30
 Xdblfault() at Xdblfault+0xac/frame 0xfe03dc30
 --- trap 0x17, rip = 0x8218c794, rsp = 0xfe044cdc9fe0, rbp =
 0xfe044cdca110 ---
 vdev_queue_aggregate() at vdev_queue_aggregate+0x34/frame 0xfe044cdca110
 vdev_queue_io_to_issue() at vdev_queue_io_to_issue+0x1f5/frame
 0xfe044cdca560
 vdev_queue_io() at vdev_queue_io+0x19a/frame 0xfe044cdca5b0
 zio_vdev_io_start() at zio_vdev_io_start+0x81f/frame 0xfe044cdca6e0
 zio_execute() at zio_execute+0x23b/frame 0xfe044cdca730
 zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca760
 vdev_mirror_io_start() at vdev_mirror_io_start+0x140/frame
 0xfe044cdca800
 zio_vdev_io_start() at zio_vdev_io_start+0x12f/frame 0xfe044cdca930
 zio_execute() at zio_execute+0x23b/frame 0xfe044cdca980
 zio_nowait() at zio_nowait+0xbe/frame 0xfe044cdca9b0
 spa_load_verify_cb() at spa_load_verify_cb+0x37d/frame 0xfe044cdcaa50
 traverse_visitbp() at traverse_visitbp+0x5a5/frame 0xfe044cdcac60
 traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcacd0
 traverse_visitbp() at traverse_visitbp+0xc66/frame 0xfe044cdcaee0
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb0f0
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb300
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb510
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb720
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcb930
 traverse_visitbp() at traverse_visitbp+0x930/frame 0xfe044cdcbb40
 traverse_dnode() at traverse_dnode+0x98/frame 0xfe044cdcbbb0
 traverse_visitbp() at traverse_visitbp+0xe59/frame 0xfe044cdcbdc0
 traverse_impl() at traverse_impl+0x79d/frame 0xfe044cdcbfd0
 traverse_dataset() at traverse_dataset+0x93/frame 0xfe044cdcc040
 traverse_pool() at traverse_pool+0x1f2/frame 0xfe044cdcc140
 spa_load_verify() at spa_load_verify+0xf3/frame 0xfe044cdcc1f0
 spa_load_impl() at spa_load_impl+0x2069/frame 0xfe044cdcc610
 spa_load() at spa_load+0x320/frame 0xfe044cdcc6d0
 spa_load_impl() at spa_load_impl+0x150b/frame 0xfe044cdccaf0
 spa_load() at spa_load+0x320/frame 0xfe044cdccbb0
 spa_load_best() at spa_load_best+0xc6/frame 0xfe044cdccc50
 spa_open_common() at spa_open_common+0x246/frame 0xfe044cdccd40
 spa_open() at spa_open+0x35/frame 0xfe044cdccd70
 dsl_pool_hold() at dsl_pool_hold+0x2d/frame 0xfe044cdccdb0
 dmu_objset_own() at dmu_objset_own+0x2e/frame 0xfe044cdcce30
 zfsvfs_create() at zfsvfs_create+0x100/frame 0xfe044cdcd050
 zfs_domount() at zfs_domount+0xa7/frame 0xfe044cdcd0e0
 zfs_mount() at zfs_mount+0x6c3/frame 0xfe044cdcd390
 vfs_donmount() at vfs_donmount+0x1330/frame 0xfe044cdcd660
 kernel_mount() at kernel_mount+0x62/frame 0xfe044cdcd6c0
 parse_mount() at parse_mount+0x668/frame 0xfe044cdcd810
 vfs_mountroot() at vfs_mountroot+0x85c/frame 0xfe044cdcd9d0
 start_init() at start_init+0x62/frame 0xfe044cdcda70
 fork_exit() at fork_exit+0x84/frame 0xfe044cdcdab0
 fork_trampoline() at fork_trampoline+0xe/frame 0xfe044cdcdab0
 --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
 KDB: enter: panic
 
 Didn't get a core because it panics before dumpdev is set.
 
 Is anyone else able to run -O0 kernels or do 

Re: Instant panic while trying run ports-mgmt/poudriere

[Konstantin Belousov]

On Thu, Aug 27, 2015 at 10:21:47AM +0300, Andriy Gapon wrote:
 On 27/08/2015 02:36, John-Mark Gurney wrote:
  We should/cannot get here w/ an empty list.  If we do, then there is
  something seriously wrong...  The current kn (which we must have as we
  are here) MUST be on the list, but as you just showed, there are no
  knotes on the list.
  
  Can you get me a print of the knote?  That way I can see what flags
  are on it?
 
 Apologies if the following might sound a little bit patronizing, but it
 seems that you have got all the facts correctly, but somehow the
 connection between them did not become clear.
 
 So:
 1. The list originally is NOT empty.  I guess that it has one entry, but
 that's an unimportant detail.
 2. This is why the loop is entered. It's a fact that it is entered.
 3. The list becomes empty precisely because the entry is removed during
 the iteration in the loop (as kib has explained).  It's a fact that the
 list became empty at least in the panic that I reported.
The only detail I can add to this explanation, which is probably third (?)
time, is that the removal is done in the filt_proc() event method, by
the call to knlist_remove_inevent().

 4. The element is not only unlinked from the list, but its memory is
 also freed.
 5. That's why we have the use after free: SLIST_FOREACH is trying to get
 a pointer to a next element from the freed memory.
 6. This is why the commit for trashing the freed memory made all the
 difference: previously the freed memory was unlikely to be re-used /
 modified, so the use-after-free had a high chance of succeeding.  It's a
 fact that in my panic there was an attempt to dereference a trashed pointer.
 7. Finally, this is why SLIST_FOREACH_SAFE helps here: we stash the
 pointer to the next element beforehand and, thus, we do not access the
 freed memory.
The additional, eighth item, should explain why the change to _SAFE() is
the correct fix, and not just a papering over the problem. Nobody except
the current thread can modify the knlist, because knlist is locked. As
a consequence, only the current element can be unlinked and removed. So
the _SAFE() iterator actually work.

 
 Please let me know if you see any fault in above reasoning or if
 something is still no clear.

___
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: Instant panic while trying run ports-mgmt/poudriere

[Andriy Gapon]

On 27/08/2015 02:36, John-Mark Gurney wrote:
 We should/cannot get here w/ an empty list.  If we do, then there is
 something seriously wrong...  The current kn (which we must have as we
 are here) MUST be on the list, but as you just showed, there are no
 knotes on the list.
 
 Can you get me a print of the knote?  That way I can see what flags
 are on it?

Apologies if the following might sound a little bit patronizing, but it
seems that you have got all the facts correctly, but somehow the
connection between them did not become clear.

So:
1. The list originally is NOT empty.  I guess that it has one entry, but
that's an unimportant detail.
2. This is why the loop is entered. It's a fact that it is entered.
3. The list becomes empty precisely because the entry is removed during
the iteration in the loop (as kib has explained).  It's a fact that the
list became empty at least in the panic that I reported.
4. The element is not only unlinked from the list, but its memory is
also freed.
5. That's why we have the use after free: SLIST_FOREACH is trying to get
a pointer to a next element from the freed memory.
6. This is why the commit for trashing the freed memory made all the
difference: previously the freed memory was unlikely to be re-used /
modified, so the use-after-free had a high chance of succeeding.  It's a
fact that in my panic there was an attempt to dereference a trashed pointer.
7. Finally, this is why SLIST_FOREACH_SAFE helps here: we stash the
pointer to the next element beforehand and, thus, we do not access the
freed memory.

Please let me know if you see any fault in above reasoning or if
something is still no clear.

-- 
Andriy Gapon
___
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: Read-only /usr/obj/ no longer kosher?

[Garrett Cooper]

 On Aug 26, 2015, at 19:03, O'Connor, Daniel dar...@dons.net.au wrote:
 
 
 On 27 Aug 2015, at 08:25, Pawel Jakub Dawidek p...@freebsd.org wrote:
 On Tue, Aug 25, 2015 at 03:32:35PM -0700, NGie Cooper wrote:
 On Tue, Aug 25, 2015 at 3:21 PM, Xin Li delp...@delphij.net wrote:
 On 08/25/15 14:55, Pawel Jakub Dawidek wrote:
 Now that I think of it, it might have been that I did
 buildworld/buildkernel before -p1. Then freebsd-update updated
 newvers.sh and then I was trying to do installworld.
 
 Yes, I can now reproduce it with source updated to -p2.
 
 Yes, that's because freebsd-version.sh is generated from the files (but
 it's not clear to me whether if it's a bug or a feature that 'make
 install' checks if it's up-to-date and decides to regenerate it...).
 
 It's a quirk for sure. If you change the behavior, people will
 definitely complain as they will now need to go back and rebuild
 everything.
 
 What we have now is misleading. People should recompile. It is rather
 rare to see security advisory which bumps only patch level and something
 that doesn't require recompilation (eg. a shell script). Current
 behaviour would make people think they are running latest patch level
 because freebsd-version says so, eventhough they only did 'make
 installworld' without rebuilding affected binaries.
 
 So..
 How hard would it be to force CC/CXX to /usr/bin/false during installworld?

Trivial in FreeBSD. Just make it so in Makefile for the installworld target, 
add false to itools, and add appropriate special casing in bsd.compiler.mk.

Doing this just prevents recompiling though, so not pjd's case.

Also, this might break someone's random usecase where they need CC/CXX to do 
something meaningful at install time, however, the likelihood of it being 
correct is slim IMHO..
___
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