date:20131214

Re: r259072 is not a happy camper...

2013-12-14 Thread Poul-Henning Kamp

In message 201312131620.25107@freebsd.org, John Baldwin writes:

 Hmmm.  Maybe do 'show lapic' and 'show apic' in ddb and paste that here?
 
 sorry about the delay...
 
 db show lapic
 lapic ID = 2
 version  = 1.0
 max LVT  = 5
 SVR  = ff (enabled)
 TPR  = 00
 In-service Interrupts:

Hmm, this is empty.  It should not be empty. :(

Never the less, the panic is further down than I thought it was.  The system 
thinks it had a valid IRQ that required an ithread to be scheduled, but when
it went to schedule the ithread, there was no thread to schedule:

Does it get a crashdump if you try?

No :-(

There may be a connection to unclean UFS filesystems (SU + TRIM, no J).

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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

Call for FreeBSD 2013Q4 (October-December) Status Reports

2013-12-14 Thread Gabor Pali

Dear FreeBSD Community,

Please note that the next submission date for the October to December
Quarterly Status Reports is January 14th, 2014, about a month away.

They do not have to be very long -- basically they may be about
anything that lets people know what is going on around the FreeBSD
Project.  Submission of reports is not restricted to committers:
Anyone who is doing anything interesting and FreeBSD-related can (and
therefore encouraged to) write one!

The preferred and easiest submission method is to use the XML
generator [1] with the result emailed as an attachment to us, that is,
mont...@freebsd.org [2].  There is also an XML template [3] which can
be filled out manually and attached if preferred.  For the expected
content and style, please study our guidelines on how to write a good
status reports [4].

To enable compilation and publication of the Q4 report as soon as
possible for the January 14th deadline, please be prompt with any
report submissions you may have.

We are looking forward to all of your 2013Q4 reports!

Thanks,
Gabor


[1] http://www.freebsd.org/cgi/monthly.cgi
[2] mailto:mont...@freebsd.org
[3] http://www.freebsd.org/news/status/report-sample.xml
[4] http://www.freebsd.org/news/status/howto.html
___
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

Re: 11.0-CURRENT panic while running a bhyve instance

2013-12-14 Thread Markiyan Kushnir

2013/12/14 Markiyan Kushnir markiyan.kush...@gmail.com:
2013/12/14 Neel Natu neeln...@gmail.com:
Hi Markiyan,

On Fri, Dec 13, 2013 at 2:35 PM, Markiyan Kushnir
markiyan.kush...@gmail.com wrote:
2013/12/13 John Baldwin j...@freebsd.org:
On Friday, December 13, 2013 5:46:20 am Markiyan Kushnir wrote:
Forgot to fill the Subject: header, re-posting it fixed.

The mailing lists strips attachments, can you post it at a URL?

Shared here:

https://drive.google.com/file/d/0B9Q-zpUXxqCnem5iYTVqLUxrcWo4cmlhdkM1c2lJa2dKak5R/edit?usp=sharing

Thanks.

It looks like something funky going on with the vcpu state. Do you
know if there was any access to the VM via 'bhyvectl' close to the
time of the panic?

Well, I don't know if there was. I would set up the same scenario
again + a script running on the host querying bhyvectl. May be I would
catch it again. Please let me know if all it makes sense, and if so,
how it can be made better.

To make it clear -- I didn't run bhyvectl when the VM was running, so
I can tell for sure that nobody was trying to interact with the VM
during its run. My first thought was that it would make sense to
(periodically) query state of the VM using bhyvectl to get info about
what was going on when it comes close to the crash...

--
Markiyan.

best
Neel

--
Markiyan.

--
Markiyan

-- Forwarded message --
From: Markiyan Kushnir markiyan.kush...@gmail.com
Date: 2013/12/13
Subject:
To: freebsd-current@freebsd.org, freebsd-virtualizat...@freebsd.org

I started some ports to compile inside a bhyve instance:

root@vm:~ # uname -a
FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0
r259250: Thu Dec 12 14:17:32 EET 2013
r...@vm.mkushnir.zapto.org:/
usr/obj/usr/src.svnup/sys/MAREK amd64

and left it running unattended. Approx. 2 hours later the host went to
panic. The bhyve instance survived after the panic and I could be able
to complete my ports compilation.

core.txt attached (gzipped)
___
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

--
John Baldwin
___
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
___
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

Re: 11.0-CURRENT panic while running a bhyve instance

2013-12-14 Thread Markiyan Kushnir

2013/12/14 Markiyan Kushnir markiyan.kush...@gmail.com:
2013/12/14 Markiyan Kushnir markiyan.kush...@gmail.com:
2013/12/14 Neel Natu neeln...@gmail.com:
Hi Markiyan,

The mailing lists strips attachments, can you post it at a URL?

Shared here:

https://drive.google.com/file/d/0B9Q-zpUXxqCnem5iYTVqLUxrcWo4cmlhdkM1c2lJa2dKak5R/edit?usp=sharing

Thanks.

It looks like something funky going on with the vcpu state. Do you
know if there was any access to the VM via 'bhyvectl' close to the
time of the panic?

--
Markiyan.

Ok, I was able to hit a similarly looking panic exactly when trying to
run bhyvectl --vm=altroot-bhyve --get-all while the VM was busy with
its own pkg delete -af. When the VM is mostly idle, bhyvectl
--get-all goes smoothly.

Now I'm thinking I might inadvertently run bhyvectl over my heavily
running VM once when I was not at the desktop and wanted to see how
things were going remotely from my office...

Here are core.txt of the two panics in a row:

https://drive.google.com/file/d/0B9Q-zpUXxqCnMUxVdGwxSEs1dE0/edit?usp=sharing

https://drive.google.com/file/d/0B9Q-zpUXxqCnREtuTXpabnQ5QXM/edit?usp=sharing

--
Markiyan.

best
Neel

--
Markiyan.

--
Markiyan

-- Forwarded message --
From: Markiyan Kushnir markiyan.kush...@gmail.com
Date: 2013/12/13
Subject:
To: freebsd-current@freebsd.org, freebsd-virtualizat...@freebsd.org

I started some ports to compile inside a bhyve instance:

root@vm:~ # uname -a
FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0
r259250: Thu Dec 12 14:17:32 EET 2013
r...@vm.mkushnir.zapto.org:/
usr/obj/usr/src.svnup/sys/MAREK amd64

and left it running unattended. Approx. 2 hours later the host went to
panic. The bhyve instance survived after the panic and I could be able
to complete my ports compilation.

dhclient can't limit bpf descriptor?

2013-12-14 Thread Tim Kientzle

Opened up an old VM from a month or so ago (r257910) and dhclient won’t start.

Specifically, dhclient complains (when run by root):
 “can’t limit bpf descriptor: Bad address”
and then immediately exits.

What does this mean?   I don’t know anything about the capabilities
framework and certainly haven’t configured it in any way.

I’ve upgraded Parallels and the Mac OS system that Parallels
is running on, so it could be related to that...

Tim

___
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

SVN commit 259045 breaks -CURRENT

2013-12-14 Thread Stefan Esser

I noticed a severe slowdown and network problems on my amd64 -CURRENT
system. By bisecting SVN revisions I identified the following commit
to be responsible:

--
r259045 | kib | 2013-12-06 22:44:13 +0100 (Fri, 06 Dec 2013) | 9 lines

Disallow optimizations which potentially remove boundary checks
for signed values due to a compiler authors considering integer
overflow as impossible.

The change follows suit of other projects taking the same measure.
--

This commit added the following line to /sys/conf/kern.mk:

CFLAGS+=   -fno-strict-overflow


The most obvious symptoms of the problem on my system are:

1) sa-spamd needs  140 seconds to start
   (instead of a few seconds)

2) SSH logins are very slow, many seconds of delay between connect
   and password prompt, several seconds after password entry until
   a command prompt appears (normally instantaneous)

In general it takes many seconds to open a TCP socket, even to
localhost.

I can perform further tests on this system, but it will be a lot
of work to locate the source files that are mis-compiled with
-fno-strict-overflow.

I'm surprised that nobody else seems to be affected by this problem,
since it is very obvious on my system and clearly caused by the
above mentioned commit.

My kernel configuration is a stripped down GENERIC plus ZFS, IPFW
and LINUX emulation. I can provide full details and a kernel that
exposes the problem on request.

Regards, STefan
___
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

Re: SVN commit 259045 breaks -CURRENT

2013-12-14 Thread Steve Kargl

On Sat, Dec 14, 2013 at 10:44:10PM +0100, Stefan Esser wrote:
 I noticed a severe slowdown and network problems on my amd64 -CURRENT
 system. By bisecting SVN revisions I identified the following commit
 to be responsible:
 
 --
 r259045 | kib | 2013-12-06 22:44:13 +0100 (Fri, 06 Dec 2013) | 9 lines
 
 Disallow optimizations which potentially remove boundary checks
 for signed values due to a compiler authors considering integer
 overflow as impossible.
 
 The change follows suit of other projects taking the same measure.
 --
 
 This commit added the following line to /sys/conf/kern.mk:
 
 CFLAGS+=   -fno-strict-overflow
 
 
 The most obvious symptoms of the problem on my system are:
 
 1) sa-spamd needs  140 seconds to start
(instead of a few seconds)
 
 2) SSH logins are very slow, many seconds of delay between connect
and password prompt, several seconds after password entry until
a command prompt appears (normally instantaneous)
 

Ah, so that explains the behavior I'm see.  Just updated a circa Aug 3rd
i386 FreeBSD to top-of-tree.  My ssh logins to my work system take 30+
seconds now. :(

-- 
steve

-- 
Steve
___
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

Re: SVN commit 259045 breaks -CURRENT

2013-12-14 Thread Stefan Esser

Am 14.12.2013 22:59, schrieb Steve Kargl:
 On Sat, Dec 14, 2013 at 10:44:10PM +0100, Stefan Esser wrote:
 I noticed a severe slowdown and network problems on my amd64 -CURRENT
 system. By bisecting SVN revisions I identified the following commit
 to be responsible:

 --
 r259045 | kib | 2013-12-06 22:44:13 +0100 (Fri, 06 Dec 2013) | 9 lines

 Disallow optimizations which potentially remove boundary checks
 for signed values due to a compiler authors considering integer
 overflow as impossible.

 The change follows suit of other projects taking the same measure.
 --

 This commit added the following line to /sys/conf/kern.mk:

 CFLAGS+=   -fno-strict-overflow


 The most obvious symptoms of the problem on my system are:

 1) sa-spamd needs  140 seconds to start
(instead of a few seconds)

 2) SSH logins are very slow, many seconds of delay between connect
and password prompt, several seconds after password entry until
a command prompt appears (normally instantaneous)

 
 Ah, so that explains the behavior I'm see.  Just updated a circa Aug 3rd
 i386 FreeBSD to top-of-tree.  My ssh logins to my work system take 30+
 seconds now. :(

You may want to test the attached patch, which reverts the above
mentioned commit.

Regards, STefan
Index: /sys/conf/kern.mk
===
--- /sys/conf/kern.mk   (revision 259396)
+++ /sys/conf/kern.mk   (working copy)
@@ -148,12 +148,6 @@
 CFLAGS+=   -ffreestanding
 
 #
-# Do not allow a compiler to optimize out overflow checks for signed
-# types.
-#
-CFLAGS+=   -fno-strict-overflow
-
-#
 # GCC SSP support
 #
 .if ${MK_SSP} != no  ${MACHINE_CPUARCH} != ia64  \
___
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

Re: SVN commit 259045 breaks -CURRENT

2013-12-14 Thread Steve Kargl

On Sat, Dec 14, 2013 at 11:11:15PM +0100, Stefan Esser wrote:
 Am 14.12.2013 22:59, schrieb Steve Kargl:
  On Sat, Dec 14, 2013 at 10:44:10PM +0100, Stefan Esser wrote:
 
  2) SSH logins are very slow, many seconds of delay between connect
 and password prompt, several seconds after password entry until
 a command prompt appears (normally instantaneous)
 
  
  Ah, so that explains the behavior I'm see.  Just updated a circa Aug 3rd
  i386 FreeBSD to top-of-tree.  My ssh logins to my work system take 30+
  seconds now. :(
 
 You may want to test the attached patch, which reverts the above
 mentioned commit.
 

I probably won't get to it until tomorrow, because I had started
a dog-food system purge including re-installing all ports.  The
laptop takes a bit a time to recompile everything.

-- 
Steve
___
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

Re: SVN commit 259045 breaks -CURRENT

2013-12-14 Thread Marc UBM

On Sat, 14 Dec 2013 13:59:04 -0800
Steve Kargl s...@troutmask.apl.washington.edu wrote:

 On Sat, Dec 14, 2013 at 10:44:10PM +0100, Stefan Esser wrote:
  I noticed a severe slowdown and network problems on my amd64 -CURRENT
  system. By bisecting SVN revisions I identified the following commit
  to be responsible:
  
  --
  r259045 | kib | 2013-12-06 22:44:13 +0100 (Fri, 06 Dec 2013) | 9 lines
  
  Disallow optimizations which potentially remove boundary checks
  for signed values due to a compiler authors considering integer
  overflow as impossible.
  
  The change follows suit of other projects taking the same measure.
  --
  
  This commit added the following line to /sys/conf/kern.mk:
  
  CFLAGS+=   -fno-strict-overflow
  
  
  The most obvious symptoms of the problem on my system are:
  
  1) sa-spamd needs  140 seconds to start
 (instead of a few seconds)
  
  2) SSH logins are very slow, many seconds of delay between connect
 and password prompt, several seconds after password entry until
 a command prompt appears (normally instantaneous)
  
 
 Ah, so that explains the behavior I'm see.  Just updated a circa Aug 3rd
 i386 FreeBSD to top-of-tree.  My ssh logins to my work system take 30+
 seconds now. :(

I observe dnsmasq causing extremely high network latency without any
visible reason - though that may not be related. I'll remove
-fno-strict-overflow, recompile kernel and see if anything changes.

Bye
Marc
___
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

Re: dhclient can't limit bpf descriptor?

2013-12-14 Thread Darren Pilgrim


On 12/14/2013 12:12 PM, Tim Kientzle wrote:

Opened up an old VM from a month or so ago (r257910) and dhclient won’t start.

Specifically, dhclient complains (when run by root):
  “can’t limit bpf descriptor: Bad address”
and then immediately exits.


Are you running a custom kernel without the Capsicum options?


___
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

Re: 11.0-CURRENT panic while running a bhyve instance

2013-12-14 Thread Neel Natu

Hi Markiyan,

On Sat, Dec 14, 2013 at 6:00 AM, Markiyan Kushnir
markiyan.kush...@gmail.com wrote:
2013/12/14 Markiyan Kushnir markiyan.kush...@gmail.com:
2013/12/14 Markiyan Kushnir markiyan.kush...@gmail.com:
2013/12/14 Neel Natu neeln...@gmail.com:
Hi Markiyan,

The mailing lists strips attachments, can you post it at a URL?

Shared here:

https://drive.google.com/file/d/0B9Q-zpUXxqCnem5iYTVqLUxrcWo4cmlhdkM1c2lJa2dKak5R/edit?usp=sharing

Thanks.

It looks like something funky going on with the vcpu state. Do you
know if there was any access to the VM via 'bhyvectl' close to the
time of the panic?

--
Markiyan.

Now I'm thinking I might inadvertently run bhyvectl over my heavily
running VM once when I was not at the desktop and wanted to see how
things were going remotely from my office…

Thanks, that helps a lot because I can see how bhyvectl could perturb
the state of the vcpu and eventually lead to a panic.

I'll submit a fix for this ASAP.

best
Neel

Here are core.txt of the two panics in a row:

https://drive.google.com/file/d/0B9Q-zpUXxqCnMUxVdGwxSEs1dE0/edit?usp=sharing

https://drive.google.com/file/d/0B9Q-zpUXxqCnREtuTXpabnQ5QXM/edit?usp=sharing

--
Markiyan.

best
Neel

--
Markiyan.

--
Markiyan

-- Forwarded message --
From: Markiyan Kushnir markiyan.kush...@gmail.com
Date: 2013/12/13
Subject:
To: freebsd-current@freebsd.org, freebsd-virtualizat...@freebsd.org

I started some ports to compile inside a bhyve instance:

root@vm:~ # uname -a
FreeBSD vm.mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0
r259250: Thu Dec 12 14:17:32 EET 2013
r...@vm.mkushnir.zapto.org:/
usr/obj/usr/src.svnup/sys/MAREK amd64

and left it running unattended. Approx. 2 hours later the host went to
panic. The bhyve instance survived after the panic and I could be able
to complete my ports compilation.

Re: Request for testing an alternate branch

2013-12-14 Thread Justin Hibbits

On Thu, 12 Dec 2013 14:15:47 -0500
John Baldwin j...@freebsd.org wrote:

 On Wednesday, December 11, 2013 5:40:30 pm Justin Hibbits wrote:
  On Wed, Dec 11, 2013 at 1:26 PM, John Baldwin j...@freebsd.org
  wrote:
   On Thursday, December 05, 2013 1:21:13 am Justin Hibbits wrote:
   I've been working on the projects/pmac_pmu branch for some time
   now to add suspend/resume as well as CPU speed change for
   certain PowerPC machines, about a year since I created the
   branch, and now it's stable enough that I want to merge it into
   HEAD, hence this request. However, it does touch several
   drivers, turning them into early drivers, such that they can
   be initialized, and suspended and resumed at a different time.
   Saying that, I do need testing from other architectures, to make
   sure I haven't broken anything.
  
   The technical details:
  
   To get proper ordering, I've extended the bus_generic_suspend()
   and bus_generic_resume() to do multiple passes.  Devices which
   cannot be enabled or disabled at the current pass level would
   return an EAGAIN. This could possibly cause problems, since it's
   an addition to an existing API rather than a new API to run
   along side it, so it needs a great deal of testing.  It works
   fine on PowerPC, but I don't have any i386/amd64 or sparc64
   hardware to test it on, so would like others who do to test it.
   I don't think that it would impact x86 at all (testing is
   obviously required), because the nexus is not an
   EARLY_DRIVER_MODULE, so all devices would be handled at the same
   pass.  But, I do know the sparc64 has an EARLY_DRIVER_MODULE()
   nexus, so that will likely be impacted.
  
   I have patches to change many x86 drivers to use
   EARLY_DRIVER_MODULE() FWIW.
  
   Also, I'm still not a fan of the EAGAIN approach.  I'd rather
   have a method in bus_if.m to suspend or resume a single device
   and to track that a device is suspended or resumed via a device_t
   flag or some such. (I think I had suggested this previously as it
   would also allow us to have a tool to suspend/resume individual
   drivers at runtime apart from a full suspend/resume request).
  
   --
   John Baldwin
  
  Understood.  You had mentioned something along those lines before.
  Is it safe/sane to partially merge a branch into HEAD?  If so, I can
  merge only the changes necessary for PMU cpufreq, and work on the
  suspend/resume separately.  I put them together because most of the
  low level code involved is the same between them.
 
 Yes, you can split them up.  However, the way to do that is to
 generate a diff and patch that into a head checkout and commit.
 There's not a good way to have 'svn merge' do it AFAIK.
 
  I do like your idea of a device_t flag, but I'm not sure what the
  best way to go with that would be.  I do already use a device_t
  flag to determine if the device is suspended, but only
  bus_generic_* access that in this patch.
  
  Would a better way be:
  * root_suspend instead of suspending its children, instead traverses
  and suspends each descendent in reverse order.
   * While doing this, insert each device upon successful suspend
  into a list.
  * For root_resume(), traverse the list back, and suspend each device
  in the reverse order.
 
 I would rather do it more the way that multipass attach now works
 where you do scans of the entire device tree as you walk the pass
 number down (during suspend) suspending any devices that are not yet
 suspended if their pass number is = current pass number, then on
 resume you do scans of the entire tree raising the pass number back
 up using similar logic to attach where you resume any suspended
 devices if the driver's pass number is = current pass number.
 
  With this, add a new method, called device_suspend_child() to
  suspend a specific child if it hasn't already been suspended.
 
 Well, I would call it 'bus_suspend_child' and 'bus_resume_child' as
 these would be bus methods in bus_if.m.
 
   * This could require modifying the PCI driver to move the device
  child suspend/resume into those functions, instead of doing that
  logic in the device_suspend/device_resume itself.
 
 Correct.  bus_generic_suspend() and bus_suspend_resume() would turn
 into loops that look a lot like bus_generic_new_pass() (so the logic
 for honoring pass numbers would happen in these routines and they
 would invoke bus_suspend_child() and bus_resume_child() to change the
 state of individual drivers).
 
 device_suspend() and device_resume() for the root device would look
 like bus_set_pass() with a similar loop that walked through the pass
 levels and invoked bus_generic_suspend/resume after each pass change
 to start the pass across the device tree.
  
  I guess, in short, I'm asking:  Is it fine if I merge only the code
  necessary for this cpufreq?  That would require making other changes
  to this before merging in, to isolate that code, but it's very
  doable.
  
  - Justin
  
 

John,

Would it make

'silent' kernel builds ?

2013-12-14 Thread Luigi Rizzo

Hi,
I was trying to make buildkernel a bit quieter (just listing
the name of the file being compiled).

I hoped to modify the  .c.o:  rules in  share/sys.mk but apparently
kernel builds generate their own Makefile using definitions in
sys/conf/kern.pre.mk .

As a result, a patch like the one below gets most of the work done
(a few extra bits are necessary to mask the awk calls, and the
'irregular' compiler invocations).

However I could not found the rule definition used to build modules,
any idea where to look ?

And finally, is there interest in this feature ?

cheers
luigi


Index: head/sys/conf/kern.pre.mk
===
--- head/sys/conf/kern.pre.mk   (revision 258360)
+++ head/sys/conf/kern.pre.mk   (working copy)
@@ -126,7 +126,12 @@
 # Optional linting. This can be overridden in /etc/make.conf.
 LINTFLAGS= ${LINTOBJKERNFLAGS}
 
-NORMAL_C= ${CC} -c ${CFLAGS} ${WERROR} ${PROF} ${.IMPSRC}
+.if defined(SILENT)
+SILENT_MAKE= @
+SILENT_GCC= @printf %s\n ---  Building  ${.IMPSRC} ---;
+.endif
+
+NORMAL_C= ${SILENT_GCC} ${CC} -c ${CFLAGS} ${WERROR} ${PROF} ${.IMPSRC}
 NORMAL_S= ${CC} -c ${ASM_CFLAGS} ${WERROR} ${.IMPSRC}
 PROFILE_C= ${CC} -c ${CFLAGS} ${WERROR} ${.IMPSRC}
 NORMAL_C_NOWERROR= ${CC} -c ${CFLAGS} ${PROF} ${.IMPSRC}
@@ -146,7 +151,7 @@
 ZFS_S= ${CC} -c ${ZFS_ASM_CFLAGS} ${WERROR} ${.IMPSRC}
 
 .if ${MK_CTF} != no
-NORMAL_CTFCONVERT= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
+NORMAL_CTFCONVERT= ${SILENT_MAKE}  ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
 .elif ${MAKE_VERSION} = 520300
 NORMAL_CTFCONVERT=
 .else

___
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

Re: SVN commit 259045 breaks -CURRENT

2013-12-14 Thread Konstantin Belousov

On Sat, Dec 14, 2013 at 02:16:27PM -0800, Steve Kargl wrote:
 On Sat, Dec 14, 2013 at 11:11:15PM +0100, Stefan Esser wrote:
  Am 14.12.2013 22:59, schrieb Steve Kargl:
   On Sat, Dec 14, 2013 at 10:44:10PM +0100, Stefan Esser wrote:
  
   2) SSH logins are very slow, many seconds of delay between connect
  and password prompt, several seconds after password entry until
  a command prompt appears (normally instantaneous)
  
   
   Ah, so that explains the behavior I'm see.  Just updated a circa Aug 3rd
   i386 FreeBSD to top-of-tree.  My ssh logins to my work system take 30+
   seconds now. :(
  
  You may want to test the attached patch, which reverts the above
  mentioned commit.
  
 
 I probably won't get to it until tomorrow, because I had started
 a dog-food system purge including re-installing all ports.  The
 laptop takes a bit a time to recompile everything.
 

Are you all running i386, compiled with gcc ?


pgp1bGAwXfMjJ.pgp
Description: PGP signature

Re: SVN commit 259045 breaks -CURRENT

2013-12-14 Thread Steve Kargl

On Sun, Dec 15, 2013 at 07:47:22AM +0200, Konstantin Belousov wrote:
 On Sat, Dec 14, 2013 at 02:16:27PM -0800, Steve Kargl wrote:
  On Sat, Dec 14, 2013 at 11:11:15PM +0100, Stefan Esser wrote:
   Am 14.12.2013 22:59, schrieb Steve Kargl:
On Sat, Dec 14, 2013 at 10:44:10PM +0100, Stefan Esser wrote:
   
2) SSH logins are very slow, many seconds of delay between connect
   and password prompt, several seconds after password entry until
   a command prompt appears (normally instantaneous)
   

Ah, so that explains the behavior I'm see.  Just updated a circa Aug 3rd
i386 FreeBSD to top-of-tree.  My ssh logins to my work system take 30+
seconds now. :(
   
   You may want to test the attached patch, which reverts the above
   mentioned commit.
   
  
  I probably won't get to it until tomorrow, because I had started
  a dog-food system purge including re-installing all ports.  The
  laptop takes a bit a time to recompile everything.
  
 
 Are you all running i386, compiled with gcc ?

The Aug 3rd system was built with gcc.  The system upgrade I
did this morning is using clang.  I rebuilt everything and
delete old things with delete-old and delete-old-libs.

-- 
Steve
___
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

Re: 'silent' kernel builds ?

2013-12-14 Thread Luigi Rizzo

On Sat, Dec 14, 2013 at 09:53:30PM -0800, Rui Paulo wrote:
 On 14 Dec 2013, at 21:45, Luigi Rizzo ri...@iet.unipi.it wrote:
 
  Hi,
  I was trying to make buildkernel a bit quieter (just listing
  the name of the file being compiled).
  
  I hoped to modify the  .c.o:  rules in  share/sys.mk but apparently
  kernel builds generate their own Makefile using definitions in
  sys/conf/kern.pre.mk .
  
  As a result, a patch like the one below gets most of the work done
  (a few extra bits are necessary to mask the awk calls, and the
  'irregular' compiler invocations).
  
  However I could not found the rule definition used to build modules,
  any idea where to look ?
 
 sys/conf/kmod.mk

... ok, which in turn ends up into share/sys.mk at least for the .c.o rule

  And finally, is there interest in this feature ?
 
 I think it would be nice to have, maybe enabled by default.  Does it still 
 print the errors? I think so, but I'm not sure.

Yes it does print errors, just checked.

I am not worried about making it a default, POLA
probably suggests otherwise and it is simple to
control it through a make.conf or environment variable.

thanks
luigi
___
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

Re: dhclient can't limit bpf descriptor?

2013-12-14 Thread Tim Kientzle


On Dec 14, 2013, at 3:16 PM, Darren Pilgrim list_free...@bluerosetech.com 
wrote:

 On 12/14/2013 12:12 PM, Tim Kientzle wrote:
 Opened up an old VM from a month or so ago (r257910) and dhclient won’t 
 start.
 
 Specifically, dhclient complains (when run by root):
  “can’t limit bpf descriptor: Bad address”
 and then immediately exits.
 
 Are you running a custom kernel without the Capsicum options?

Nope, it’s an unmodified GENERIC kernel.

Tim

___
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

Re: SVN commit 259045 breaks -CURRENT

2013-12-14 Thread Konstantin Belousov

On Sat, Dec 14, 2013 at 09:56:04PM -0800, Steve Kargl wrote:
 On Sun, Dec 15, 2013 at 07:47:22AM +0200, Konstantin Belousov wrote:
  On Sat, Dec 14, 2013 at 02:16:27PM -0800, Steve Kargl wrote:
   On Sat, Dec 14, 2013 at 11:11:15PM +0100, Stefan Esser wrote:
Am 14.12.2013 22:59, schrieb Steve Kargl:
 On Sat, Dec 14, 2013 at 10:44:10PM +0100, Stefan Esser wrote:

 2) SSH logins are very slow, many seconds of delay between connect
and password prompt, several seconds after password entry until
a command prompt appears (normally instantaneous)

 
 Ah, so that explains the behavior I'm see.  Just updated a circa Aug 
 3rd
 i386 FreeBSD to top-of-tree.  My ssh logins to my work system take 30+
 seconds now. :(

You may want to test the attached patch, which reverts the above
mentioned commit.

   
   I probably won't get to it until tomorrow, because I had started
   a dog-food system purge including re-installing all ports.  The
   laptop takes a bit a time to recompile everything.
   
  
  Are you all running i386, compiled with gcc ?
 
 The Aug 3rd system was built with gcc.  The system upgrade I
 did this morning is using clang.  I rebuilt everything and
 delete old things with delete-old and delete-old-libs.

And, the clang-built kernel times out the connections ? On i386 ?


pgp7zUKeqeQtW.pgp
Description: PGP signature

Re: SVN commit 259045 breaks -CURRENT

2013-12-14 Thread Steve Kargl

On Sun, Dec 15, 2013 at 08:43:22AM +0200, Konstantin Belousov wrote:
 On Sat, Dec 14, 2013 at 09:56:04PM -0800, Steve Kargl wrote:
  
  The Aug 3rd system was built with gcc.  The system upgrade I
  did this morning is using clang.  I rebuilt everything and
  delete old things with delete-old and delete-old-libs.
 
 And, the clang-built kernel times out the connections ? On i386 ?

With a clang built kernel, it takes 30+ seconds for a 
ssh to connect to my work system.  Prior to the upgrade,
connection speed was unnoticable.  I won't be able to
test Stefan suggested fix until tomorrow.  I'm currently
chasing down iconv issues.

-- 
Steve
___
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

Re: SVN commit 259045 breaks -CURRENT

2013-12-14 Thread Marc UBM

On Sun, 15 Dec 2013 07:47:22 +0200
Konstantin Belousov kostik...@gmail.com wrote:

 On Sat, Dec 14, 2013 at 02:16:27PM -0800, Steve Kargl wrote:
  On Sat, Dec 14, 2013 at 11:11:15PM +0100, Stefan Esser wrote:
   Am 14.12.2013 22:59, schrieb Steve Kargl:
On Sat, Dec 14, 2013 at 10:44:10PM +0100, Stefan Esser wrote:
   
2) SSH logins are very slow, many seconds of delay between connect
   and password prompt, several seconds after password entry until
   a command prompt appears (normally instantaneous)
   

Ah, so that explains the behavior I'm see.  Just updated a circa Aug 3rd
i386 FreeBSD to top-of-tree.  My ssh logins to my work system take 30+
seconds now. :(
   
   You may want to test the attached patch, which reverts the above
   mentioned commit.
   
  
  I probably won't get to it until tomorrow, because I had started
  a dog-food system purge including re-installing all ports.  The
  laptop takes a bit a time to recompile everything.
  
 
 Are you all running i386, compiled with gcc ?

I'm running amd64 compiled with clang; uname -a:

FreeBSD xxx 11.0-CURRENT FreeBSD 11.0-CURRENT #15
r258254:259095M: Sun Dec  8 12:11:33 CET 2013
xxx:/usr/obj/usr/src/sys/SUBMARINE_SMP  amd64

I'm recompiling right now to see if maybe I'm having a different
issue.

Bye
Marc
___
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

Re: r259072 is not a happy camper...

Call for FreeBSD 2013Q4 (October-December) Status Reports

Re: 11.0-CURRENT panic while running a bhyve instance

Re: 11.0-CURRENT panic while running a bhyve instance

dhclient can't limit bpf descriptor?

SVN commit 259045 breaks -CURRENT

Re: SVN commit 259045 breaks -CURRENT

Re: SVN commit 259045 breaks -CURRENT

Re: SVN commit 259045 breaks -CURRENT

Re: SVN commit 259045 breaks -CURRENT

Re: dhclient can't limit bpf descriptor?

Re: 11.0-CURRENT panic while running a bhyve instance

Re: Request for testing an alternate branch

'silent' kernel builds ?

Re: SVN commit 259045 breaks -CURRENT

Re: SVN commit 259045 breaks -CURRENT

Re: 'silent' kernel builds ?

Re: dhclient can't limit bpf descriptor?

Re: SVN commit 259045 breaks -CURRENT

Re: SVN commit 259045 breaks -CURRENT

Re: SVN commit 259045 breaks -CURRENT

21 matches

Site Navigation

Mail list logo

Footer information