Re: openjdk7 dtrace support

[Mark Johnston]

On Wed, Oct 09, 2013 at 09:55:51PM +0800, Patrick Dung wrote:
> Hello, 
> 
> 
> I would like to know it there is dtrace support in the openjdk7?

Not yet on FreeBSD, unless there's something I'm missing. Some work
needs to be done on the port in order to get it working.

hotspot/make/bsd/makefiles/dtrace.make only does anything if it detects
that it's running on Darwin; that'd probably be a good place to start
for anyone interested in working on this.

-Mark
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Fuse on FreeBSD 9.2

[Mark Felder]

On Tue, Oct 8, 2013, at 7:08, Łukasz P wrote:
> Thank you - I'll give it a try today.
> Can you confirm that doing rsync with this fuse version is stable?
> 
> Can you please tell us which fuse-based file system have you used?
> 

My main use case these days is ntfs-3g, and I no longer get panics when
doing mass file operations including rsync. :-)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Fuse on FreeBSD 9.2

[Mark Felder]

On Tue, Oct 8, 2013, at 6:34, Mark Felder wrote:
> 
> I think the "fix" is the new from-scratch fuse module in FreeBSD 10,
> which in my experience works flawlessly. Perhaps you should instead see
> if someone is willing to backport that fuse module to 9.x?
>

Well actually the description on the WhatsNew/FreeBSD10 page has me on
the fence about whether or not the port and the new module in FreeBSD 10
share the same source. You could diff it to find out. I'm a bit short on
time this morning to dig into that. :-)

"The FreeBSD port (including the clean-room BSD-licenced
reimplementation of the kernel module) was created during 2 summer of
code mandates and being revived by gnn recently. The functionality in
this commit matches the content of fusefs-kmod port, which doesn't need
to be installed anymore for -CURRENT setups."

https://wiki.freebsd.org/WhatsNew/FreeBSD10
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Fuse on FreeBSD 9.2

[Mark Felder]

On Tue, Oct 8, 2013, at 5:21, Łukasz P wrote:
> Hello,
> 
> Please let me know if anyone is up to fix fuse on FreeBSD 9.x ?
> 
> Particularly this bug: 
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=182739
> 
>  
> 
> I'm willing to pay for the fix.
> 
>  

I think the "fix" is the new from-scratch fuse module in FreeBSD 10,
which in my experience works flawlessly. Perhaps you should instead see
if someone is willing to backport that fuse module to 9.x?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD SNMP OID Question

[Mark Saad]

On Tue, Sep 17, 2013 at 2:11 PM, Dan Nelson  wrote:

> In the last episode (Sep 17), Mark Saad said:
> >   Can someone shed some light on a OID mystery I have. I am using cacti
> > to trend some snmp data off a bunch of FreeBSD servers.
> >
> > I noticed someone added a graph to a cluster for UCDavis - ssRawSwapIn /
> > UCDavis - ssRawSwapOut  . The OIDs are .1.3.6.1.4.1.2021.11.62 /
> > .1.3.6.1.4.1.2021.11.63  Their description is  Number of blocks swapped
> > in / Number of blocks swapped out .
>
> > # snmpwalk -c MyPassword -v2c -Of server00 .1.3.6.1.4.1.2021.11.62.0
> > .iso.org.dod.internet.private.
> > enterprises.ucdavis.systemStats.ssRawSwapIn.0
> > = Counter32: 3588
>
> That's a counter, so it's reporting the total number of pageins since boot
> (or since snmp started, depending on the particular value you're fetching).
> Cacti should be able to poll that OID and graph the difference over time to
> show pageins/sec.
>
>
> --
> Dan Nelson
> dnel...@allantgroup.com
>

Dan
  I guess to better refine the question , what is raw swap vs  the sysctl
vm.stats.vm.v_swappgs{out/in} . I see that net-snmpd has ssSwapOut and
ssRawSwapOut . where raw is the current value and "cooked" (ssswap{out/in})
is the average value .  I am just at a loss when I am trying to debug this
graph issue as the "cooked" oid returns negative ints and the raw returns
positive ints, but the sysctrls and top show no usage ?

Has anyone seen this before ?

-- 
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

FreeBSD SNMP OID Question

[Mark Saad]

All
  Can someone shed some light on a OID mystery I have. I am using cacti
to trend some snmp data off a bunch of FreeBSD servers.

I noticed someone added a graph to a cluster for UCDavis - ssRawSwapIn /
UCDavis - ssRawSwapOut  . The OIDs are .1.3.6.1.4.1.2021.11.62 /
.1.3.6.1.4.1.2021.11.63  Their description is  Number of blocks swapped
in / Number of blocks swapped out .

The mystery is the graphs show pages swapping in and out all the time.
However the sysctls for swap usage show no indication of swap being used

# sysctl -a |fgrep -i swap
vm.swap_enabled: 1
vm.nswapdev: 1
vm.swap_async_max: 4
vm.swap_idle_threshold2: 10
vm.swap_idle_threshold1: 2
vm.stats.vm.v_swappgsout: 0
vm.stats.vm.v_swappgsin: 0
vm.stats.vm.v_swapout: 0
vm.stats.vm.v_swapin: 0
vm.disable_swapspace_pageouts: 0
vm.defer_swapspace_pageouts: 0
vm.swap_idle_enabled: 0

# uptime
 2:51PM  up 203 days, 22:29, 1 user, load averages: 0.00, 0.01, 0.00


# snmpwalk -c MyPassword -v2c -Of server00 .1.3.6.1.4.1.2021.11.62.0
.iso.org.dod.internet.private.
enterprises.ucdavis.systemStats.ssRawSwapIn.0
= Counter32: 3588



I am using net-snmp-5.4.2.1 on FreeBSD 9.1-RELEASE amd64



See *http://net-snmp.sourceforge.net/docs/mibs/ucdavis.html


-- 
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Discussing ideas or wish list

[Mark Felder]

On Thu, Aug 8, 2013, at 10:34, Mark Felder wrote:
> After the EoL of FreeBSD 8 (estimated June 30, 2015) the old package
> tools are scheduled to be removed from FreeBSD. This change will be
> MFC'd back to 9-STABLE and the release at that time (perhaps
> 9.4-RELEASE?) will not have the old pkg_* tools. This seems a bit odd to
> happen in the middle of a series because of POLA, but we can't support
> the old package tools forever and FreeBSD 9.1-9.3 will have given you
> plenty of opportunity to migrate to the new package format and ease the
> upgrade to FreeBSD 10.x.
> 

Note this isn't set in stone. Watch the Roadmap on this page:

https://wiki.freebsd.org/pkgng/CharterAndRoadMap
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Discussing ideas or wish list

[Mark Felder]

On Thu, Aug 8, 2013, at 9:54, Patrick Dung wrote:
>
> 1) Perl version change within Major release
> If I remembered correctly, FreeBSD 9.0 shipped with perl 5.12 packages in
> the DVD.
> But in FreeBSD 9.1, Perl 5.14 is shipped.
> 
> I think Perl version should be consistent in the FreeBSD 9 series.
> The change of Perl version may make user difficult to upgrade other perl
> packages due to dependency issues.

The ports tree is a "rolling release"  and decides what the default perl
version is, not the FreeBSD release. Let's ignore that though and take a
peek into history using FreeBSD 8 series as an example because it's
closer to EoL.

Perl 5.8.0 is officially released July 18, 2002.
Perl 5.8.9 is officially EoL on Nov 6, 2008.

FreeBSD 8.0 released Nov 25, 2009. The ports tree's default Perl version
at that point in time is Perl 5.8.9. Both Perl 5.8.9 and 5.10.1 are
available as packages at that time.

FreeBSD 8.4 released June 7, 2013. The ports tree's default Perl version
at that point in time is 5.14.2.

FreeBSD 8.4 could be the last release in the FreeBSD 8.x series. Its
estimated EoL is June 30, 2015.

Do you see the problem with having to support an ancient Perl version
that is 13 years old? I'd suspect many modern Perl applications to not
even work on Perl 5.8.9.

> I know pkgng should replaced the old package management tools in FreeBSD
> 10, I hope the situation would improve.
> 

After the EoL of FreeBSD 8 (estimated June 30, 2015) the old package
tools are scheduled to be removed from FreeBSD. This change will be
MFC'd back to 9-STABLE and the release at that time (perhaps
9.4-RELEASE?) will not have the old pkg_* tools. This seems a bit odd to
happen in the middle of a series because of POLA, but we can't support
the old package tools forever and FreeBSD 9.1-9.3 will have given you
plenty of opportunity to migrate to the new package format and ease the
upgrade to FreeBSD 10.x.

> 2) pkgng
> I think it has checksum checking on the files in the packages.
> Could pkgng detect the packages was being tampered?

man pkg-check

  pkg check -s is used to find invalid checksums for installed packages.

> Or how can user authenticate that the package is build by FreeBSD?
> 

I don't think packages are signed yet, but this is permitted by the new
pkg design and will hopefully happen before too long.

> 3) FreeBSD's own systat
> Yes. there is bsdsar in the ports, but I would like to see improvement.
> For example, stat for multiple CPU, number of open files/context
> switches, one statistics file per day, etc...
> 

I think systat is great, too. We could probably import some
functionality from OpenBSD as I recall their systat has more features.


Thank you for your feedback and I hope I've answered a couple of your
questions.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: After the FreeBSD VM crash, file system in VM got rolled back to some old previous state causing data loss

[Mark Felder]

Virtualbox is very aggressive about caching writes. This is how it
achieves its perceived speed. I wouldn't expect to see this happen on
real hardware. I might have to try this out though and see if I can
reproduce it reliably.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: panic: kmem_map too small at heavy packet traffic

[Mark Felder]

I've been under the impression that synproxy was broken for quite some
time, but I know there has been a lot of work on pf in HEAD so I can't
be sure where it might stand there. Can anyone confirm/deny this?

And not to discourage you, but the pf documentation does say "Routine
use of this option is not recommended, however, as it breaks expected
TCP protocol behavior when the server can't process the request..."

However, panics are never good and hopefully someone can help you figure
it out.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: bin/176713: [patch] nc(1) closes network socket too soon

[Mark Delany]

> servers running certain protocols.  For example, the rules of the SMTP
> protocol... just to name one... require that a client wait until the
> server has sent out an initial greeting banner before the client sends
> anything to the server.  Some SMTP servers are lenient about enforcing
> this protocol rule, so in practice it may often not be necessary to wait

A while back "fast talkers" as they were called, were a known
signature of some spam bots. The guess is that they would just write
the whole SMTP transaction in one write() immediately following the
connect() and be done with it. A useful optimization when you're
blatting out billions of spam.

You don't see a big mention of this in search engines, so I don't know
how prevalent they are now.

Point being that such an option might be useful to avoid triggering
any detectors that might still be looking for this.


Mark.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: writing a rc.d script

[Mark Felder]

On Sun, 07 Jul 2013 06:45:46 -0500, Aryeh Friedman  
 wrote:



I have a program I am making a port for that also requires a
/usr/local/etc/rc.d script is there anywhere I can find documentation
on how write one and/or a template file to follow?



Start with another similar port if possible. Make sure you use rclint to  
verify its correctness. There is a ton of information inside /etc/rc.subr  
and /usr/ports/Mk/* which may help you write your port where the  
documentation falls short.

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

Re: UNIVERSE_TARGET doesn't seem to work

[Mark Johnston]

On Mon, Jun 03, 2013 at 02:13:38PM -0700, Navdeep Parhar wrote:
> On 05/30/13 18:43, Navdeep Parhar wrote:
> > I build kernel-toolchain and MAKE_JUST_KERNELS (often with NO_CLEAN, but
> > not this time) as part of my pre-commit checklist.  It doesn't seem to
> > work after the switch to bmake.  What am I missing?  This on a system
> > at r251171 with nothing in make.conf or src.conf:
> > 
> > # make -j12 universe UNIVERSE_TARGET=kernel-toolchain
> > --- universe_prologue ---
> > --
> >>>> make universe started on Thu May 30 18:19:44 PDT 2013
> > --
> > `universe_amd64_prologue' was not built (made 0, flags 2009, type b01)!
> > `universe_arm_prologue' was not built (made 0, flags 2009, type b01)!
> > `universe_i386_prologue' was not built (made 0, flags 2009, type b01)!
> > `universe_ia64_prologue' was not built (made 0, flags 2009, type b01)!
> > `universe_mips_prologue' was not built (made 0, flags 2009, type b01)!
> > `universe_pc98_prologue' was not built (made 0, flags 2009, type b01)!
> > `universe_powerpc_prologue' was not built (made 0, flags 2009, type 
> > b01)!
> > `universe_sparc64_prologue' was not built (made 0, flags 2009, type 
> > b01)!
> > `universe_epilogue' was not built (made 1, flags 2009, type b01)!
> > `universe_epilogue' has .ORDER dependency against universe_amd64 (made 
> > 1, flags 3009, type 301)
> > `universe_epilogue' has .ORDER dependency against universe_arm (made 1, 
> > flags 3009, type 301)
> > `universe_epilogue' has .ORDER dependency against universe_i386 (made 
> > 1, flags 3009, type 301)
> > `universe_epilogue' has .ORDER dependency against universe_ia64 (made 
> > 1, flags 3009, type 301)
> > `universe_epilogue' has .ORDER dependency against universe_mips (made 
> > 1, flags 3009, type 301)
> > `universe_epilogue' has .ORDER dependency against universe_pc98 (made 
> > 1, flags 3009, type 301)
> > `universe_epilogue' has .ORDER dependency against universe_powerpc 
> > (made 1, flags 3009, type 301)
> > `universe_epilogue' has .ORDER dependency against universe_sparc64 
> > (made 1, flags 3009, type 301)
> > 
> > # make -j12 -DMAKE_JUST_KERNELS JFLAG=-j12 universe 
> > (same result)
> 
> It is the -j causing the problem.  I tried with an empty /usr/obj too
> but that didn't help either.  Does anyone know of a way around this?
> Building without -j is quite tedious.

You can try passing 'JFLAG=-j12' to the make universe invocation. It's
not the same in that each target is built with -j12 rather rather than
building 12 targets at once. But it lets me finish a make universe
overnight on my laptop.

-Mark
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: GSOC: Qt front-ends

[Mark Saad]

On Apr 21, 2013, at 4:11 PM, Justin Edward Muniz  wrote:

> Hello everyone once again,
> 
> I decided to split this from my previous thread because the nature of
> my questions has changed. I benefited from the last thread, and I am
> grateful to those who responded to it.
> 
> For me Google Summer of Code is a big opportunity, and my interest in
> contributing to the open source community is fairly limited to FreeBSD for
> many reasons. I know that my application may have a better chance of being
> approved if I have a mentor to help me with my endeavors.
> 
> I currently have three project ideas in mind; however I need to
> understand which one would be the most beneficial, and try to find a
> mentor, before I create my proposal. Eventually I would like to develop
> each application and release them along with a meta-package that comprises
> of them all. For now, I need to focus on just one of the three.
> 
> Originally I was interested in developing a Qt front-end for
> freebsd-update; indeed most of my research has been for that project.
> However, I am also interested in furthering kports -- which seems to be
> notoriously buggy, has broken package functionality, and is a mammoth of an
> application; the last development for kports was in 2009. I also am
> interested in developing a graphical application to customize the FreeBSD
> kernel.
> 
> I have compiled a list of features that I would like to concentrate on
> for each project. Some of the features are far less important than others,
> so my actual application may omit some of them, or consider them optional.
> If it would be appropriate I will certainly share my lists, but since the
> lists are long I don't want to spam the mailing-list. I am new to this
> community after all!
> 
> If anyone is interested in discussing these possibilities or just one
> of them in particular, I will greatly appreciate any advice, insight,
> concerns, criticism, or ideas. Ideally I am also looking to talk with
> anyone who might be interested in mentoring my Google Summer of Code
> project.
> 
> Justin Muniz
> __


Justin I say stick to  FreeBSD-update . My reason is, as Pkgng becomes more 
popular , a front end for ports will be less useful as binary packages become 
more popular . Kports is a monster program , you should set a reasonable goal 
,and target dates; which may be hard with a cleanup project .   Also a update 
notifier for kde that handles FreeBSD update would be very useful . 

My 2cents .
---
Mark saad | mark.s...@longcount.org

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

Re: close(2) while accept(2) is blocked

[John-Mark Gurney]

Bakul Shah wrote this message on Sat, Mar 30, 2013 at 13:22 -0700:
> On Sat, 30 Mar 2013 09:14:34 PDT John-Mark Gurney  wrote:
> > 
> > As someone else pointed out in this thread, if a userland program
> > depends upon this behavior, it has a race condition in it...
> > 
> > Thread 1Thread 2Thread 3
> > enters routine to read
> > enters routine to close
> > calls close(3)
> > open() returns 3
> > does read(3) for orignal fd
> > 
> > How can the original threaded program ensure that thread 2 doesn't
> > create a new fd in between?  So even if you use a lock, this won't
> > help, because as far as I know, there is no enter read and unlock
> > mutex call yet...
> 
> It is worse. Consider:
> 
>   fd = open(file,...);
>   read(fd, ...);
> 
> No guarantee read() gets data from the same opened file!
> Another thread could've come along, closed fd and pointed it
> to another file. So nothing is safe. Might as well stop using
> threads, right?!

Nope, you need your threads to cooperate w/ either locks or some
ownership mechanism like token passing...  As long as only one
thread own the fd, you won't have troubles...

> We are talking about cooperative threads where you don't have
> to assume the worst case.  Here not being notified on a close

Multiple people have said when threads cooperate without locks, but
no one has given a good example where they do...  The cases you list
below are IMO special (and extreme) cases...

We were talking about "cooperating" threads in a general purpose
langage like Java where you can not depend upon your other threads
doing limited amount of work...

> event can complicate things. As an example, I have done
> something like this in the past: A frontend process validating
> TCP connections and then passing on valid TCP connections to
> another process for actual service (via sendmsg() over a unix
> domain). All the worker threads in service process can do a
> recvmsg() on the same fd. They process whatever tcp connection
> they get. Now what happens when the frontend process is
> restarted for some reason?  All the worker threads need to
> eventually reconnect to a new unix domain posted by the new
> frontend process. You can handle this multiple ways but
> terminating all the blocking syscalls on the now invalid fd is
> the simplest solution from a user perspective.

This'd make an interesting race... Not sure if it could happen, but
close(), closes the receiving fd, but another thread is in the process
of receiving an fd and puts the new fd in the close of the now closed
unix domain socket...  I can draw a more detailed diagram if you want..

> > I decided long ago that this is only solvable by proper use of locking
> > and ensuring that if you call close (the syscall), that you do not have
> > any other thread that may use the fd.  It's the close routine's (not
> > syscall) function to make sure it locks out other threads and all other
> > are out of the code path that will use the fd before it calls close..
> 
> If you lock before close(), you have to lock before every
> other syscall on that fd. That complicates userland coding and
> slows down things when this can be handled more simply in the
> kernel.

There is "ownership" that can be passed, such as via kqueue _ONESHOT
w/ multiple threads which allows you to avoid locking and only one
thread ever owns the fd...

> Another usecase is where N worker threads all accept() on the
> same fd. Single threading using a lock defeats any performance
> gain.

In this case you still need to do something special since what happens
if one of the worker threads opens a file and/or listen/accept socket
as part of it's work?

Thread 1Thread 2Thread 3
about to call accept but
  after flag check
sets flag that close
  is going to be called
accept connect
process connection
close listen'd socket
open socket as part of
  processing gets same fd
calls listen on socket
calls accept on socket

And there we have it, a race condition...  You can't always guarantee
what your worker threads do, if you can, it's good, but we need to make
sure that beginner programs don't get into traps like these...  They
can easily make the mistake of saying, well, since close kicks all
my threads out, I'll just do that instead of making sure that they
don't have a race 

Re: close(2) while accept(2) is blocked

[Mark]

> As someone else pointed out in this thread, if a userland program
> depends upon this behavior, it has a race condition in it...
> 
> Thread 1  Thread 2Thread 3
>   enters routine to read
> enters routine to close
> calls close(3)
>   open() returns 3
>   does read(3) for orignal fd
> 
> How can the original threaded program ensure that thread 2 doesn't
> create a new fd in between?  So even if you use a lock, this won't
> help, because as far as I know, there is no enter read and unlock
> mutex call yet...
> 
> I decided long ago that this is only solvable by proper use of locking
> and ensuring that if you call close (the syscall), that you do not have
> any other thread that may use the fd.  It's the close routine's (not
> syscall) function to make sure it locks out other threads and all other
> are out of the code path that will use the fd before it calls close..
> 
> If someone could describe how this new eject a person from read could
> be done in a race safe way, then I'd say go ahead w/ it...  Otherwise
> we're just moving the race around, and letting people think that they
> have solved the problem when they haven't...

Right. The only "safe" way is to have all blocking syscalls on the
same fd in the same process return to userland. This would need to be
initiated in the close() syscall.

Btw. Threads aren't the only scenario. A signal handler can also close
the fd. Maybe not advised, but I have used this "technique" to force a
return from a blocking accept() call since about FBSD4.x


Mark.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: close(2) while accept(2) is blocked

[John-Mark Gurney]

Bakul Shah wrote this message on Fri, Mar 29, 2013 at 16:54 -0700:
> On Fri, 29 Mar 2013 14:30:59 PDT Carl Shapiro  wrote:
> > 
> > In other operating systems, such as Solaris and MacOS X, closing the
> > descriptor causes blocked system calls to return with an error.
> 
> What happens if you select() on a socket and another thread
> closes this socket?  Ideally select() should return (with
> EINTR?) so that the blocking thread can some cleanup action.
> And if you do that, the blocking accept() case is not really
> different.
> 
> There is no point in *not* telling blocking threads that the
> descriptor they're waiting on is one EBADF and nothing is
> going to happen.
> 
> > It is not obvious whether there is any benefit to having the current
> > blocking behaviour. 
> 
> This may need some new kernel code but IMHO this is worth fixing.

As someone else pointed out in this thread, if a userland program
depends upon this behavior, it has a race condition in it...

Thread 1Thread 2Thread 3
enters routine to read
enters routine to close
calls close(3)
open() returns 3
does read(3) for orignal fd

How can the original threaded program ensure that thread 2 doesn't
create a new fd in between?  So even if you use a lock, this won't
help, because as far as I know, there is no enter read and unlock
mutex call yet...

I decided long ago that this is only solvable by proper use of locking
and ensuring that if you call close (the syscall), that you do not have
any other thread that may use the fd.  It's the close routine's (not
syscall) function to make sure it locks out other threads and all other
are out of the code path that will use the fd before it calls close..

If someone could describe how this new eject a person from read could
be done in a race safe way, then I'd say go ahead w/ it...  Otherwise
we're just moving the race around, and letting people think that they
have solved the problem when they haven't...

I think I remeber another thread about this from a year or two ago,
but I couldn't find it...  If someone finds it, posting a link would
be nice..

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

 "All that I will do, has been done, All that I have, has not."
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

pkgng questions

[Mark Saad]

All
 I am wondering if there is a way to prevent a pkg from being updated.
For example, i want to build a port with custom options that the pkgng
repos will not support, and therefore
when I run pkg update && pkg upgrade I do not want it to upgrade my
custom package.  I cant find any way to do this. Any ideas ?


-- 
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: gjournal +UFS - anyone actually use it?

[Mark Saad]

On Mar 6, 2013, at 5:55 AM, Wojciech Puchar  
wrote:

>> I was using it to store large MySQL myisam tables , speed was acceptable at 
>> the time .  I never had any fs corruption and it worked as expected .
>> 
>> At the time I set it up I remember there was some chatter about how slow 
>> gjournal was compared to ufs with softupdate .
> 
> did some tests yesterday on 25GB partition.
> 
> i simulated journal on SSD using 2GB malloc backed ramdisk (md0). UFS 
> partition mounted async as gjournal recommends.
> 
> test: unpacking kernel sources to multiple directories until disk gets full
> 
> simulates write heavy I/O.
> 
> gjournal+SATA drive (seagate constellation ES 500GB) with write cache 
> disabled - 14 minutes 20 seconds.
> 
> write cache enabled - 14 minutes 5 seconds (nearly no difference).
> 
> UFS+journalled softupdates, no gjournal, disk write cache on - 26 minutes 44 
> seconds. disk write cache off - was too lazy to wait after an hour.
> 
> With gjournal it is not only faster, but it doesn't make other I/O activity 
> crawling.
> 

Interesting I will have to try this; can you post the exact test steps . Also 
what type of controller were you using and what kernel / version .

> 
>> 
>> Fast forward to today I almost always use ufs with softupdate journal , new 
>> in FreeBSD 9.0 and available as a patch to 6.x, 7.x , and 8.x
> 
> The problem is as follows:
> 
> SU+J makes sure that metadata will get consistent. NOT DATA. And this is 
> quite a mess if you get UPS failure under high load.
> 
> gjournal does journal everything.
> 

Not exactly, ufs mounted  with default options insures data is written sync and 
metadata asynchronous . Standard Softupdate (no journal) improves upon this by 
limiting what ops need to write to the disk. It had some short falls  for edge 
case operations; which softupdate journal resolved by journaling the metadata 
ops that were not protected / covered by standard softupdate .  

See 
http://jeffr-tech.livejournal.com/24357.html



>> This is better supported now , as more people use it in new 9.x builds  .
>> 
>>> i think about journal on SSD.
>> 
>> I believe this is only and option in geom journal ,
> 
> SSDs are not expensive today. i can get 128GB SSD and create 20GB journal 
> just to limit wear. and possibly use the rest of SSD to store read-intensive 
> data.
> 

I wonder if how trim / no trim effects the journal wear . 

> the way gjournal writes to journal device (sequential) is very friendly for 
> SSD too.
> 
> Small SLC-based SSD would be best but i don't see anything on the market with 
> acceptable price for now.
> 
>> I am not sure if you can relocate a suj journal to an alternate disk.
> no you can't. But still you will end with consistent metadata but not 
> consistent data. I recovered it but still it took a time and lots of checking.
> 
> 
> 
> 
> gjournal doesn't seem to be elegant in case of journal failure (i simulated 
> it with forced removal of ramdisk with mdconfig).
> 
> TONS of messages in logs, but still - no data loss, just you have to shutdown 
> system, boot from pendrive, remove journal, fsck (just for sure), and then 
> add journal again


I would be careful of using the md for the journal . Something makes me think 
it will play nicer when you remove that then a real failure .  Try a USB stick 
for the journal; and pull it out while running your test case.  That to me 
seams evil enough to break this setup . 

Let me know what happens .

Also when testing su+j I ran the following test case . Extract ports via 
portsnap extract , build world with -j4 . Let the box warm up the yank the 
power and then boot the box back up and see what happens . 
--
Mark saad | mark.s...@longcount.org
 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: gjournal +UFS - anyone actually use it?

[Mark Saad]

On Mar 5, 2013, at 1:35 PM, Wojciech Puchar  
wrote:

> if yes - how about performance on production server.

I have used gjournal on 7.x amd64 . Using in disk journals . This was on a hp 
dl380 g5 using 6 300gb  sas disks in a raid 1+0 . 

I was using it to store large MySQL myisam tables , speed was acceptable at the 
time .  I never had any fs corruption and it worked as expected . 

At the time I set it up I remember there was some chatter about how slow 
gjournal was compared to ufs with softupdate . 

Fast forward to today I almost always use ufs with softupdate journal , new in 
FreeBSD 9.0 and available as a patch to 6.x, 7.x , and 8.x 

This is better supported now , as more people use it in new 9.x builds  .

> i think about journal on SSD.

I believe this is only and option in geom journal , I am not sure if you can 
relocate a suj journal to an alternate disk . It should be faster . All I can 
say here is give it a try and see what happens . 

Hope that helps 

> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


---
Mark saad | mark.s...@longcount.org

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

Re: looking for someone to fix humanize_number (test cases included)

[John-Mark Gurney]

Clifton Royston wrote this message on Tue, Dec 25, 2012 at 09:46 -1000:
> On Tue, Dec 25, 2012 at 08:23:55AM -1000, Clifton Royston wrote:
> > On Tue, Dec 25, 2012 at 07:20:37AM -1000, Clifton Royston wrote:
> > > On Mon, Dec 24, 2012 at 12:00:01PM +, 
> > > freebsd-hackers-requ...@freebsd.org wrote:
> > > > From: John-Mark Gurney 
> > > > To: hack...@freebsd.org
> > > > Subject: looking for someone to fix humanize_number (test cases
> > > > included)
> > > > 
> > > > I'm looking for a person who is interested in fixing up humanize_number.
> > ...
> > > > So I decided to write a test program to test the output, and now I'm 
> > > > even
> > > > more surprised by the output...  Neither 7.2-R nor 10-current give what
> > > > I expect are the correct results...
> > ...
> > 
> >   I am bemused.
> 
>   I correct myself: the function works fine, and there are no bugs I
> could find, though it's clear the man page could emphasize the correct
> usage a bit more.
> 
>   I had to read the source several times and start on debugging it
> before I understood the correct usage of the flag values with the scale
> and flags parameters, despite the man page stating:
> 
>  The following flags may be passed in scale:
> 
>HN_AUTOSCALE Format the buffer using the lowest multiplier pos-
> sible.
>HN_GETSCALE  Return the prefix index number (the number of
> times number must be divided to fit) instead of
> formatting it to the buffer.
> 
>  The following flags may be passed in flags:
> 
>HN_DECIMAL   If the final result is less than 10, display it
> using one digit.
> ...
>HN_DIVISOR_1000  Divide number with 1000 instead of 1024.
> 
>   That is, certain flags must be passed in flags and others must only
> be passed in scale - a bit counter-intuitive.  Also, scale == 0 is
> clearly not interpreted as AUTOSCALE, but I am not yet clear how it is
> being handled - it seems somewhat like AUTOSCALE but not identical.
> 
>   When the test program constant table is updated to pass the scale
> flags as specified, as well as fixing the bugs mentioned in the
> previous emails, it all passes except for the one (intentional?)
> inconsistency that "k" is used in place of "K" if HN_DECIMAL is
> enabled.
> 
>   The bug in the transfer speed results which prompted this inquiry
> suggests that perhaps some clients of humanize_number in the codebase
> are also passing the scale parameters incorrectly.  I would propose
> accepting HN_AUTOSCALE and HN_GETSCALE in the flags field (they don't
> overlap with other values) while continuing to accept them in the scale
> field for backwards compatibility.  Trivial diff below.

Sorry I didn't get back to this, but now I have a few minutes...

> + getscale  = (flags | scale) & HN_GETSCALE;

This isn't good:
#define HN_IEC_PREFIXES 0x10
#define HN_GETSCALE 0x10

If someone sets HN_IEC_PREFIXES, they'll acidentally enable _GETSCALE..

We could do something anoying by changing the value of _GETSCALE, and
then leaving some legacy code to accept the old _GETSCALE on the scale
input...  This would let new code work, but would break new code on
old libraries...  So, I don't see an easy way to fix this...

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

 "All that I will do, has been done, All that I have, has not."
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: SA-13:02/libc and FreeBSD 6

[Mark Johnston]

On Thu, Feb 21, 2013 at 01:53:44PM -0500, Mark Saad wrote:
> All
>  So Xin's patch works so far I see no unexpected issues; can I get a MFC ?
> Also on a unrelated MFC request would someone be willing to merge
> stable/7/sys/netinet/tcp_input.cr246999 into 6-STABLE . This cleanly
> applied and I saw no issues.

The tcp_input.c change was merged as r247136.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: SA-13:02/libc and FreeBSD 6

[Mark Johnston]

On Thu, Feb 21, 2013 at 01:53:44PM -0500, Mark Saad wrote:
> All
>  So Xin's patch works so far I see no unexpected issues; can I get a MFC ?
> Also on a unrelated MFC request would someone be willing to merge
> stable/7/sys/netinet/tcp_input.cr246999 into 6-STABLE . This cleanly
> applied and I saw no issues.
> 

I can do the latter MFC later today if no one has any objections.

> 
> 
> On Wed, Feb 20, 2013 at 6:18 PM, Adrian Chadd  wrote:
> 
> > On 20 February 2013 12:01, Mark Saad  wrote:
> > > Xin
> > >  I am rebuilding now, I'll let you know how it works.
> >
> > As I've said before, if someone wants to take ownership of 6.x and
> > backport changes / push them into STABLE_6, be my guest. Yahoo was
> > doing that for some unsupported old releases for a while.
> >
> > They'd still stay unsupported.. well, as long as there's not a big
> > group of 6.x users standing up and taking ownership.
> >
> > (Same can be said of what's going to happen to 7.x soon.)
> >
> >
> >
> > Adrian
> >
> 
> 
> 
> -- 
> mark saad | nones...@longcount.org
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: SA-13:02/libc and FreeBSD 6

[Mark Saad]

All
 So Xin's patch works so far I see no unexpected issues; can I get a MFC ?
Also on a unrelated MFC request would someone be willing to merge
stable/7/sys/netinet/tcp_input.cr246999 into 6-STABLE . This cleanly
applied and I saw no issues.



On Wed, Feb 20, 2013 at 6:18 PM, Adrian Chadd  wrote:

> On 20 February 2013 12:01, Mark Saad  wrote:
> > Xin
> >  I am rebuilding now, I'll let you know how it works.
>
> As I've said before, if someone wants to take ownership of 6.x and
> backport changes / push them into STABLE_6, be my guest. Yahoo was
> doing that for some unsupported old releases for a while.
>
> They'd still stay unsupported.. well, as long as there's not a big
> group of 6.x users standing up and taking ownership.
>
> (Same can be said of what's going to happen to 7.x soon.)
>
>
>
> Adrian
>



-- 
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Question on timecounter hardware / What cpu flag is constant_tsc

[Mark Saad]

All
 I am looking into an issue with timecounter hardware on a number of HP
DL165 G7's

They all run FreeBSD 9.1-RELEASE and all have the same CPU and firmware.
However they report strange results when you probe  kern.timecounter.choice
and
kern.timecounter.hardware

Take this example

 ssh root@ssr4 "sysctl kern.timecounter.choice"
kern.timecounter.choice: TSC-low(-100) ACPI-safe(850) HPET(950) i8254(0)
dummy(-100)

ssh root@ssr4 "sysctl kern.timecounter.hardware"
kern.timecounter.hardware: HPET

dmidecode -s processor-version
AMD Opteron(TM) Processor 6212

dmidecode -s processor-frequency
2600 MHz
Unknown

from dmesg.boot
CPU: AMD Opteron(TM) Processor 6212  (2600.06-MHz K8-class
CPU)
  Origin = "AuthenticAMD"  Id = 0x600f12  Family = 15  Model = 1  Stepping
= 2

Features=0x178bfbff

Features2=0x1e98220b
  AMD Features=0x2e500800
  AMD
Features2=0x1c9bfff,>

vs

ssh root@ssr3 "sysctl kern.timecounter.choice"
kern.timecounter.choice: TSC-low(1000) ACPI-safe(850) HPET(950) i8254(0)
dummy(-100)

 ssh root@ssr3 "sysctl kern.timecounter.hardware"
kern.timecounter.hardware: TSC-low

dmidecode -s processor-version
AMD Opteron(TM) Processor 6212

dmidecode -s processor-frequency
2600 MHz
Unknown

from dmesg.boot
CPU: AMD Opteron(TM) Processor 6212  (2600.06-MHz K8-class
CPU)
  Origin = "AuthenticAMD"  Id = 0x600f12  Family = 15  Model = 1  Stepping
= 2

Features=0x178bfbff

Features2=0x1e98220b
  AMD Features=0x2e500800
  AMD
Features2=0x1c9bfff,>


So my questions, what is the preferred time counter here ? In linux using
TSC is preferred over hpet and to tell if you have a trusted TSC your cpu
needs to support feature constant_tsc . Does anyone know what cpu feature
this is; is it listed in my a fore mentioned dmesg.boot feature lists ?

TIA


-- 
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: SA-13:02/libc and FreeBSD 6

[Mark Saad]

Xin
 I am rebuilding now, I'll let you know how it works.


On Wed, Feb 20, 2013 at 1:32 PM, Xin Li  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 02/20/13 09:29, Mark Saad wrote:
> > All I was wondering if anyone knows, off hand if SA-13:02/libc
> > applies to FreeBSD 6-STABLE and if it would be committed to the
> > 6-STABLE branch ?
>
> The patch itself won't apply, there were many changes after the last
> 6-STABLE branch.
>
> Here is a patch backported for stable/6 but I do not have time to set
> up a testing environment for it, if you do, please let me know if the
> patch worked or not, thanks!
>
> Cheers,
> - --
> Xin LI https://www.delphij.net/
> FreeBSD - The Power to Serve!   Live free or die
> -BEGIN PGP SIGNATURE-
>
> iQEcBAEBCgAGBQJRJRanAAoJEG80Jeu8UPuzyf0H/AyoNHoCSoXxTRl4tu0NOFsR
> lZ/5O7h+YMK6LejwQxEfbb9vnNkRYmP5FtM4Ja7cQjqvFM24tL4RXtoazdYQcgid
> /X+ExMIghF+/5fbEDt8x03lKQB8G5Ua3HTIqQfZoM5LREdzlXsyxREep4VspgT+y
> GTofcvwReT7LJZyYqeYmLq+tJLOy/gWkl95MJPz/0E58+H/xqCwTEol8vDhUqTYh
> WuBfRzNpY2OLnc5RStKZ+Vj+vkNIFHeHrOmwcYby+MGYl8V89pb+MjKP/mEITxcv
> 8NF8Ti52yY8ZtG7aS8tvAoY6qeAqWknv1yiHg+IZrgvtkXSBefExUSCAzS2z1G8=
> =m/h0
> -END PGP SIGNATURE-
>



-- 
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: SA-13:02/libc and FreeBSD 6

[Mark Saad]

I am aware its EOL'd but there are still a number of us stuck with 6-STABLE
.


On Wed, Feb 20, 2013 at 12:31 PM, Fleuriot Damien  wrote:

> http://www.freebsd.org/security/#sup
>
> 6 has been EOL for a looong time.
>
> So hmmm, guessing you won't see a patch.
>
>
>
> On Feb 20, 2013, at 6:29 PM, Mark Saad  wrote:
>
> > All
> >  I was wondering if anyone knows, off hand if SA-13:02/libc applies to
> > FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch ?
> >
> > --
> > mark saad | nones...@longcount.org
> > ___
> > freebsd-hackers@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "
> freebsd-hackers-unsubscr...@freebsd.org"
>
>


-- 
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

SA-13:02/libc and FreeBSD 6

[Mark Saad]

All
  I was wondering if anyone knows, off hand if SA-13:02/libc applies to
FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch ?

-- 
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: ZFS regimen: scrub, scrub, scrub and scrub again.

[Mark Felder]

On Wed, 23 Jan 2013 14:26:43 -0600, Chris Rees  wrote:



So we have to take your word for it?
Provide a link if you're going to make assertions, or they're no more  
than

your own opinion.


I've heard this same thing -- every vdev == 1 drive in performance. I've  
never seen any proof/papers on it though.

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

ipv6 equivalent to ipv4_addr_IF in network.subr?

[Mark Felder]

Hi all,

At work we have several standalone webservers with lots of IPs... let's  
say x.x.x.100 - 200. That's a LOT of "ifconfig_IF_alias0, alias1,  
alias2..." to maintain, and it's also painful when we need to move an IP  
to a different server which happens occasionally. The right solution for  
this is to use ranges with ipvr_addr_IF="x.x.x.100-200/24" and if you need  
to move an IP you just create a gap.For example, if we needed to move the  
IP .126 we'd just change it to:



ipv4_addr_IF="x.x.x.100-125/24 x.x.x.127-200/32"


This works great! But what about IPv6? We use corresponding IPv6 IPs so if  
a customer actually wants IPv6 enabled it's as easy as adding the   
record. So this leaves us with having to maintain 100 aliases again, and  
when you create a gap you have to renumber all of those alias numbers or  
leave things like "ifconfig_IF_alias67="inet6 up" strewn throughout the  
config to fill the gaps. It's just not something worth maintaining long  
term and I'd like a way to do ranges for IPv6 as well.


I've been playing with adding ipv6_addr_IF support to network.subr and it  
certainly works but the main problem is that I'm only dealing with decimal  
ranges. This would *not* work with any IPv6 hex ranges unless someone more  
clever than I can think of a good way to code that up.


Mostly a blatant ripoff of ipv4_addrs_common() we come up with this:


# ipv6_addrs_common if action
#   Evaluate the ifconfig_if_ipv6 arguments for interface $if and
#   use $action to add or remove ipv6 addresses from $if.
ipv6_addrs_common()
{
local _ret _if _action _cidr _cidr_addr
local _ipaddr _prefixlen _range _ipnet _iplow _iphigh _ipcount
_ret=1
_if=$1
_action=$2
   # get ipv6-addresses
cidr_addr=`get_if_var $_if ipv6_addrs_IF`
   for _cidr in ${cidr_addr}; do
_ipaddr=${_cidr%%/*}
_prefixlen="/"${_cidr##*/}
_range=${_ipaddr##*:}
_ipnet=${_ipaddr%:*}
_iplow=${_range%-*}
_iphigh=${_range#*-}
   # clear prefixlen when removing aliases
if [ "${_action}" = "-alias" ]; then
_prefixlen=""
fi
   _ipcount=${_iplow}
while [ "${_ipcount}" -le "${_iphigh}" ]; do
eval "ifconfig ${_if} inet6 ${_action}  
${_ipnet}:${_ipcount}${_prefixlen}"

_ipcount=$((${_ipcount}+1))
_ret=0
   # only the first ipaddr in a subnet need the  
real prefixlen

if [ "${_action}" != "-alias" ]; then
_prefixlen="/128"
fi
done
done
   return $_ret
}



But again, has no concept of any non-decimal ranges. However, this would  
still be invaluable to us and perhaps anyone else out there managing large  
numbers of IPs on a server.


So two questions:

1) With its current limitations (decimal ranges only) would this ever be  
accepted into network.subr?
2) Can anyone assist me with correctly modifying ipv6if() so this works  
standalone? Without ipv6if() modification it will always return 1 and skip  
setting up any ipv6 addresses on the interface because it doesn't find any  
ifconfig_IF_ipv6 or ipv6_ifconfig_IF in rc.conf.




Thanks!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: IBM blade server abysmal disk write performances

[Mark Felder]

On Thu, 17 Jan 2013 16:12:17 -0600, Karim Fodil-Lemelin  
 wrote:


"SAS controllers may connect to SATA devices, either directly connected  
using native SATA protocol or through SAS expanders using SATA Tunneled  
Protocol (STP)."
 The systems is currently put in place using SATA instead of SAS  
although its using the same interface and backplane connectors and the  
drives (SATA) show as da0 in BSD _but_ with the SATA drive we get *much*  
better performances. I am thinking that something fancy in that SAS  
drive is not being handled correctly by the FreeBSD driver. I am  
planning to revisit the SAS drive issue at a later point (sometimes next  
week).


Your SATA drives are connected directly not with an interposer such as the  
LSISS9252, correct? If so, this might be the cause of your problems.  
Mixing SAS and SATA drives is known to cause serious performance issues  
for almost every JBOD/controller/expander/what-have-you. Change your  
configuration so there is only one protocol being spoken on the bus (SAS)  
by putting your SATA drives behind interposers which translate SAS to SATA  
just before the disk. This will solve many problems.

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

Re: Failsafe on kernel panic

[Mark Johnston]

On Thu, Jan 17, 2013 at 04:14:21PM +0200, Sami Halabi wrote:
> Hi,
> Upon panic no auto restart occurs.
> How do I know/activate these watchdogs?
> Sami

You can try starting watchdogd with 'service watchdogd onestart', and
have it automatically start during boot by adding
'watchdogd_enable="YES"' to rc.conf.

You can test by starting watchdogd and sending SIGKILL to it - if
everything's working properly, the system should reboot after the
timeout period (16s by default).

If you don't have a hardware watchdog (or have one that isn't supported
by any drivers), watchdogd will fail to start.

-Mark

> בתאריך 17 בינו 2013 15:35, מאת "Ian Lepore" :
> 
> > On Thu, 2013-01-17 at 08:38 +0200, Sami Halabi wrote:
> > > btw: i don't see any options in my kernel config for KBD / Unatteneded ,
> > th
> > > eonly thing that mention its
> > > is: device ukbd
> > >
> > > Sami
> >
> > I think if you don't have any kdb options turned on, then a panic should
> > automatically store a crashdump to swap, then reboot the machine.  If
> > that's not working, perhaps it locks up trying to store the dump?
> >
> > If the hardware has a watchdog timer, enabling that might be the best
> > way to ensure a reboot on any kind of crash or hang.
> >
> > -- Ian
> >
> >
> > > On Thu, Jan 17, 2013 at 6:45 AM, Sami Halabi  wrote:
> > >
> > > > Its only a kernel option? There is no flag to pass to the loader?
> > > >
> > > > SAMI
> >  <>  17  2013 05:18,  "Ian Lepore" :
> > > >
> > > > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote:
> > > >> > Thank you for your response, very helpful.
> > > >> > one question - how do i configure auto-reboot once kernel panic
> > occurs?
> > > >> >
> > > >> > Sami
> > > >> >
> > > >>
> > > >> From src/sys/conf/NOTES, this may be what you're looking for...
> > > >>
> > > >> #
> > > >> # Don't enter the debugger for a panic. Intended for unattended
> > operation
> > > >> # where you may want to enter the debugger from the console, but still
> > > >> want
> > > >> # the machine to recover from a panic.
> > > >> #
> > > >> options KDB_UNATTENDED
> > > >>
> > > >> But I think it only has meaning if you have option KDB in effect,
> > > >> otherwise it should just reboot itself after a 15 second pause.
> > > >>
> > > >> -- Ian
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> >
> > > >> > On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin 
> > wrote:
> > > >> >
> > > >> > > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote:
> > > >> > > > Hi everyone,
> > > >> > > > I have a production box, in which I want to install new kernel
> > > >> without
> > > >> > > any
> > > >> > > > remotd kvn.
> > > >> > > > my problem is its 2 hours away, and if a kernel panic occurs I
> > got a
> > > >> > > > problem.
> > > >> > > > I woner if I can seg failsafe script to load the old kernel in
> > case
> > > >> of
> > > >> > > > psnic.
> > > >> > >
> > > >> > > man nextboot (if you are using UFS)
> > > >> > >
> > > >> > > --
> > > >> > > John Baldwin
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >>
> > >
> > >
> > > --
> > > Sami Halabi
> > > Information Systems Engineer
> > > NMS Projects Expert
> > > FreeBSD SysAdmin Expert
> > > ___
> > > freebsd-hackers@freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > > To unsubscribe, send any mail to "
> > freebsd-hackers-unsubscr...@freebsd.org"
> >
> >
> >
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: IBM blade server abysmal disk write performances

[Mark Felder]

On Tue, 15 Jan 2013 08:12:14 -0600, Karim Fodil-Lemelin  
 wrote:



Hi,

I'm struggling getting FreeBSD 9.1 properly work on an IBM blade server
(HS22). Here is a dd output from Linux CentOS vs FreeBSD 9.1.



GNU dd is heavily buffered unless you tell it not to be. There really is  
no reason why you should want dd to be buffered by default. How can you  
trust that your attempt at writing raw data to a device actually completed  
if it's buffered?

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

Re: [PATCH] Add WITH_DEBUG_FILES knob to enable separate debug files

[Mark Johnston]

On Dec 23, 2012 10:18 PM, "Garrett Cooper"  wrote:
>
> On Sat, Dec 22, 2012 at 8:13 PM, Alfred Perlstein  wrote:
> > On 12/22/12 6:14 PM, Jan Beich wrote:
> >>
> >> Ed Maste  writes:
> >>
> >>> When this knob is set standalone debug files for shared objects are
> >>> built and installed in /usr/lib/debug/.debug.  GDB
> >>> searches this path for debug data.
> >>
> >> [...]
> >> What about ports? They are not allowed to install outside of PREFIX.
> >>
> >>$ cd multimedia/cuse4bsd-kmod
> >>$ make install PREFIX=/tmp/aaa PKG_DBDIR=/tmp/pkg WITH_DEBUG=
> >>[...]
> >>install -C -o root -g wheel -m 444   libcuse4bsd.a /tmp/aaa/lib
> >>install -s -o root -g wheel -m 444 libcuse4bsd.so.1 /tmp/aaa/lib
> >>install -o root -g wheel -m 444libcuse4bsd.so.1.debug
> >> /usr/lib/debug/tmp/aaa/lib
> >>install: /usr/lib/debug/tmp/aaa/lib: No such file or directory
> >>*** [_libinstall] Error code 71
> >
> > I have a patch for this.  I am building world to see what happens, if
you
> > want to try it, or comment on it, please let me know.
> >
> > Changes are:
> >   base DEBUGDIR on LIBDIR for ports
> >   create intermediate directories for debug objs.
>
> One thing about this (and the original patch) that may or may not
> make sense is that DEBUGDIR should be undefined and passed in via
> CFLAGS in the Makefile (reason being is that it would reduce
> duplication IMO and it's less duplicated magic juju hanging around
> some gdb header files).

FWIW, newer versions of gdb have done this.

> Another thing that might be a good idea is that the changes in
> bsd.lib.mk diverge from standard expectations for the file extension
> (.symbols -> .debug), so at the very least this should be documented.
> Finally, what about debug symbols for programs (bsd.prog.mk)? I
> assume that's coming soon, but I figured I should ask :).

I have an extension of Ed's patch which handles bsd.prog.mk at
http://people.freebsd.org/~markj/patches/debug_symbols/debug_symbols_full.patch

> Thanks!
> -Garrett
>
> PS Awesome solution for the ports issue :).
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [PATCH] Add WITH_DEBUG_FILES knob to enable separate debug files

[Mark Johnston]

On Dec 23, 2012 10:55 PM, "Alfred Perlstein"  wrote:
>
> On 12/23/12 7:20 PM, Garrett Cooper wrote:
>>
>> On Sat, Dec 22, 2012 at 9:42 PM, Alfred Perlstein  wrote:
>>
>> ...
>> lfred/freebsd/tmp/usr/bin/ld: __vdso_gettimeofday.So:
>> invalid SHT_GROUP entry
>> /usr/obj/usr/home/alfred/freebsd/tmp/usr/bin/ld: __vdso_gettimeofday.So:
no
>> group info for section .text.__vdso_gettimeofday
>> /usr/obj/usr/home/alfred/freebsd/tmp/usr/bin/ld: __vdso_gettimeofday.So:
no
>> group info for section .text.__vdso_clock_gettime
>> /usr/obj/usr/home/alfred/freebsd/tmp/usr/bin/ld: __vdso_gettimeofday.So:
>> unknown [0] section `' in group [__vdso_gettimeofday]
>> /usr/obj/usr/home/alfred/freebsd/tmp/usr/bin/ld: __vdso_gettimeofday.So:
>> unknown [0] section `' in group [__vdso_clock_gettime]
>> __vdso_gettimeofday.So: file not recognized: File format not recognized
>> cc: error: linker command failed with exit code 1 (use -v to see
invocation)
>> *** [libc.so.7.full] Error code 1
>> 1 error
>> *** [lib/libc__L] Error code 2
>> 1 error
>> *** [libraries] Error code 2
>> 1 error
>> *** [_libraries] Error code 2
>> 1 error
>> *** [buildworld] Error code 2
>> 1 error
>>  Is RANLIB not being called properly (for lack of a better example:
>> https://forums.oracle.com/forums/thread.jspa?messageID=8438118 )?
>> Cheers,
>> -Garrett
>>
> I had "WITH_CTF=yes" in my /etc/make.conf so this appears to be fallout
of WITH_CTF=yes.  Basically this seems incompatible with dtrace unless I
figure it out further.

I have WITH_CTF=YES in src.conf and I've been able to complete a
buildworld+installworld with an extension of this patch. The errors are
also occurring
before objcopy has done anything, so I don't see why they might be related.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

looking for someone to fix humanize_number (test cases included)

[John-Mark Gurney]

I'm looking for a person who is interested in fixing up humanize_number.

The other day I copied some data from a 7.2-R box to a 9.1-stable box
and did a du -shc and a du-skc to check the results...  I noticed the -h
run dropped from 11M to 10M, which I thought was weird...  Then I looked
at the results from the -k run, but the new machine had a larger result
(I copied from UFS to ZFS)...  It turns out that humanize_number was
broken when doing rounding...  No longer does humanize_number round up
at .5 or more of the prefix..

So I decided to write a test program to test the output, and now I'm even
more surprised by the output...  Neither 7.2-R nor 10-current give what
I expect are the correct results...

Feel free to take a look at the test program posted to:
http://people.freebsd.org/~jmg/humanize_numbers/

The .c contains what I think the output should be.

So far the bugs I know of:
1) rounding is incorrect (started this whole search)
2) buffer calculation is incorrect in some cases, index 11 should fit
   but doesn't
3) some cases zero is returned though it isn't zero, more like 0T for 512 G
   (indexes 16, 17, 22, 23)
4) man page is missing required sys/types.h include

I'll work to get the code into the tree once we get it in a good state.

Please cc me as I'm not subscribed to -hackers.

Thanks.

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

 "All that I will do, has been done, All that I have, has not."
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Syslog-ng weirdness on 9.1-RELEASE

[Mark Saad]

looks like  i jumped the gun its a bug in syslog-ng

https://bugzilla.balabit.com/show_bug.cgi?id=193


On Wed, Dec 12, 2012 at 11:50 AM, Mark Saad  wrote:

> All
>  I am wondering if anyone has seen this. I pulled down the 9.1-RELEASE
> install media and did a clean install . After installing some ports from
> the packages on
> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable
>
> I noticed that syslog-ng is spinning out of control with a stock config.
>
> ps shows I have two syslog-ng pids
>
> the lower numbed pid is idle and the higher numbed pid is spinning out of
> control
>
> Here is a truss of each
>
> # truss -p 20979
> SIGNAL 17 (SIGSTOP
>
> # truss -p 20980
> kevent(3,{},0,{0xb,EVFILT_READ,0x0,0,0x56fb,0x80251b5f0},8,{10.861307840
> }) = 1 (0x1)
> clock_gettime(4,{2199.064214776 })   = 0 (0x0)
> kevent(3,{},0,{0xb,EVFILT_READ,0x0,0,0x56fb,0x80251b5f0},8,{10.860672308
> }) = 1 (0x1)
> clock_gettime(4,{2199.064899380 })   = 0 (0x0)
> kevent(3,{},0,{0xb,EVFILT_READ,0x0,0,0x56fb,0x80251b5f0},8,{10.859987704
> }) = 1 (0x1)
> clock_gettime(4,{2199.065608622 })   = 0 (0x0)
> kevent(3,{},0,{0xb,EVFILT_READ,0x0,0,0x56fb,0x80251b5f0},8,{10.859278462
> }) = 1 (0x1)
> clock_gettime(4,{2199.066240031 })   = 0 (0x0)
> kevent(3,{},0,{0xb,EVFILT_READ,0x0,0,0x56fb,0x80251b5f0},8,{10.858647053
> }) = 1 (0x1)
> clock_gettime(4,{2199.066876796 })   = 0 (0x0)
> kevent(3,{},0,{0xb,EVFILT_READ,0x0,0,0x56fb,0x80251b5f0},8,{10.858010288
> }) = 1 (0x1
>
> # procstat -f 20979
>   PID COMM   FD T V FLAGS REF  OFFSET PRO NAME
> 20979 syslog-ngtext v r r   -   - -
> /usr/local/sbin/syslog-ng
> 20979 syslog-ng cwd v d r   -   - -
> /
> 20979 syslog-ngroot v d r   -   - -
> /
> 20979 syslog-ng   0 v c r   1   0 -
> /dev/null
> 20979 syslog-ng   1 v c -w---   2   0 -
> /dev/null
> 20979 syslog-ng   2 v c -w---   2   0 -
> /dev/null
>
>
> # procstat -f 20980
>   PID COMM   FD T V FLAGS REF  OFFSET PRO NAME
> 20980 syslog-ngtext v r r   -   - -
> /usr/local/sbin/syslog-ng
> 20980 syslog-ng cwd v d r   -   - -
> /var/db
> 20980 syslog-ngroot v d r   -   - -
> /
> 20980 syslog-ng   0 v c r   1   0 -
> /dev/null
> 20980 syslog-ng   1 v c -w---   2   0 -
> /dev/null
> 20980 syslog-ng   2 v c -w---   2   0 -
> /dev/null
> 20980 syslog-ng   3 k - rw---   1   0 -
> -
> 20980 syslog-ng   4 p - rw---   1   0 -
> -
> 20980 syslog-ng   5 s - rw---n---   2   0 UDS
> /var/db/syslog-ng.ctl
> 20980 syslog-ng   6 p - rw---n---   2   0 -
> -
> 20980 syslog-ng   7 p - rw---n---   1   0 -
> -
> 20980 syslog-ng   8 v r rw---   1   16384 -
> -
> 20980 syslog-ng   9 s - rw---n---   2   0 UDD /var/run/log
> 20980 syslog-ng  10 s - rw---n---   2   0 UDD /var/run/logpriv
> 20980 syslog-ng  11 v c rn---   2   0 -
> /dev/klog
> 20980 syslog-ng  12 p - rw---n---   2   0 -
> -
> 20980 syslog-ng  13 p - rw---n---   1   0 -
> -
> 20980 syslog-ng  14 p - rw---n---   2   0 -
> -
> 20980 syslog-ng  15 p - rw---n---   1   0 -
> -
> 20980 syslog-ng  16 p - rw---n---   2   0 -
> -
> 20980 syslog-ng  17 p - rw---n---   1   0 -
> -
> 20980 syslog-ng  18 p - rw---n---   2   0 -
> -
> 20980 syslog-ng  19 p - rw---n---   1   0 -   -
>
> Here is the config
>
> # cat /usr/local/etc/syslog-ng.conf
>
>
> #
> # Default syslog-ng.conf file which collects all local logs into a
> # single file called /var/log/messages.
> #
>
> @version: 3.3
> @include "scl.conf"
>
> source s_local {
> system();
> internal();
> };
>
> source s_network {
> udp();
> };
>
> destination d_local {
> file("/var/log/messages");
> };
>
> log {
> source(s_local);
>
> # uncomment this line to open port 514 to receive messages
> #source(s_network);
> destination(d_local);
> };
>
>
> Here are the packages I installed.
>
> bash-4.2.37
> ca_root_nss-3.13.6
> cciss_vol_status-1.10
> compat6x-amd64-6.4.604000.200810_3
> compat7x-amd64-7.3.703000.201008_1
> curl-7.24.0_1
> db41-4.1.25_4
> 

Syslog-ng weirdness on 9.1-RELEASE

[Mark Saad]

-2.7.3_3
recordproto-1.14.1
renderproto-0.11.1
rsync-3.0.9_2
ruby-1.8.7.370,1
ruby18-bdb-0.6.6
sqlite3-3.7.14.1
sudo-1.8.6.p3_1
syslog-ng-3.3.6_3
unzip-6.0_1
vim-lite-7.3.669
xbitmaps-1.1.1
xextproto-7.2.0
xproto-7.0.22


Anyone have any ideas ?

-- 
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Using PC-Sysinstall for automated network installs of FreeBSD

[Mark Saad]

On Nov 17, 2012, at 12:19 AM, Warren Block  wrote:

> On Fri, 16 Nov 2012, Mark Saad wrote:
> 
>> On Nov 16, 2012, at 8:44 PM, Warren Block  wrote:
>> 
>>> On Fri, 16 Nov 2012, Warren Block wrote:
>>> 
>>>> Trying to start this from SYSLINUX almost works.  My menu config just does
>>> 
>>> Actually, it does work on a real machine.  It stalls on a VirtualBox VM 
>>> during or after the NFS root mount.
>> 
>> Strange , I will test it on virtualbox when I get some time next week . I 
>> did a lot of the testing initially on VMware esxi 4.0 and I did not have any 
>> issues related to VM stuff . What version of vbox did you use ? What network 
>> interface choice did you use in vbox ?
> 
> VirtualBox 4.1.22, FreeBSD 9-stable amd64 host.  Only the "PCnet-FAST III 
> (Am79C973)" can pxe-boot, and only in bridged mode.

Does this nic pxe boot other versions of FreeBSD ?  Isn't there a way to make 
it think it has a intel em nic?

---
Mark saad | mark.s...@longcount.org

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

Fwd: Using PC-Sysinstall for automated network installs of FreeBSD

[Mark Saad]

> 
> On Nov 16, 2012, at 8:35 PM, Warren Block  wrote:
> 
>> On Fri, 16 Nov 2012, Mark Saad wrote:
>> 
>>> Useful paths on /export, /export/install/freebsd/9.1/{i386,amd64}
>>> this is the contents of the install media rsync'd to a local filesystem
>> 
>> Do you have a way to choose either i386 or amd64 installs?
> 
> For my setup no , I just manually change the symlinks . 
> 
>> 
>>> 5 I changed my rc.conf to start a simple shell script and not the
>>> bsdinstall bits
>> 
>> Maybe you mean "/etc/rc.local" there?
>> 
> Yes that was a typo rc.local 
> 
>>> export TERM=vt220
>>> 
>>> echo "o  PC-SYSINSTALL "
>>> exec /conf/picker.sh
>> 
>> 
>> Trying to start this from SYSLINUX almost works.  My menu config just does
>> 
>> menu label FreeBSD 9 Install
>> pxe {serverip}:/usr/tftpboot/images/fbsd9ins/boot/pxeboot
>> 
>> The kernel boots, it gets to
>> 
>> Trying to mount root from nfs: []...
>> NFS ROOT: {serverip}:/usr/tftpboot/images/fbsd9ins
>> 
>> and then it stops and just sits.  NFS mount of that directory works on 
>> another system.  Anything obvious I should check?  I know pxeboot needs to 
>> be recompiled for some things, but can't recall the details.
> 
> Well I would check to see if your have a  default loader build , if your 
> loader was rebuilt with HAS_TFTPSUPPORT or something like that , it will not 
> work .  
> 
> What's in your exports file ? Also what's in your dhcpd config ? 
> 
> ---
> Mark saad | mark.s...@longcount.org
> 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Using PC-Sysinstall for automated network installs of FreeBSD

[Mark Saad]

On Nov 16, 2012, at 8:44 PM, Warren Block  wrote:

> On Fri, 16 Nov 2012, Warren Block wrote:
> 
>> Trying to start this from SYSLINUX almost works.  My menu config just does
> 
> Actually, it does work on a real machine.  It stalls on a VirtualBox VM 
> during or after the NFS root mount.

Strange , I will test it on virtualbox when I get some time next week . I did a 
lot of the testing initially on VMware esxi 4.0 and I did not have any issues 
related to VM stuff . What version of vbox did you use ? What network interface 
choice did you use in vbox ? 

---
Mark saad | mark.s...@longcount.org

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

Using PC-Sysinstall for automated network installs of FreeBSD

[Mark Saad]

 > /boot/loader.conf
runCommand=echo 'boot_serial="YES"' >> /boot/loader.conf
runCommand=echo 'comconsole_speed="9600"' >> /boot/loader.conf
runCommand=echo 'console="comconsole,vidconsole"' >> /boot/loader.conf
runCommand=cp /mnt/sysctl.conf /etc
runCommand=cp /mnt/motd /etc
runCommand=cp /mnt/ttys /etc
runCommand=cp /mnt/sshd_config /etc/ssh/
runCommand=mkdir -p /root/.ssh/
runCommand=chmod 700 /root/.ssh/
runCommand=cp /mnt/authorized_keys /root/.ssh/
runCommand=chmod 600 /root/.ssh/authorized_keys

# Set up date/time
runCommand=cp /usr/share/zoneinfo/UTC /etc/localtime
runCommand=touch /etc/wall_cmos_clock
runCommand=adjkerntz -a

# Install packages
runCommand=pkg_add /mnt/All/bash-4.2.37.tbz
runCommand=pkg_add /mnt/All/vim-lite-7.3.632.tbz
runCommand=pkg_add /mnt/All/rsync-3.0.9_1.tbz
runCommand=pkg_add /mnt/All/perl-5.14.2_2.tbz
runCommand=pkg_add /mnt/All/python27-2.7.3_3.tbz
runCommand=pkg_add /mnt/All/ruby-1.8.7.370,1.tbz
runCommand=pkg_add /mnt/All/lua-5.1.5_4.tbz
runCommand=pkg_add /mnt/All/sudo-1.8.5.p3.tbz
runCommand=pkg_add /mnt/All/portaudit-0.6.0.tbz
runCommand=pkg_add /mnt/All/curl-7.24.0.tbz
runCommand=pkg_add /mnt/All/openldap-client-2.4.32_1.tbz
runCommand=pkg_add /mnt/All/pam_ldap-1.8.6_2.tbz
runCommand=pkg_add /mnt/All/pam_mkhomedir-0.2.tbz
runCommand=pkg_add /mnt/All/nss-3.13.6.tbz
runCommand=pkg_add /mnt/All/portupgrade-2.4.9.9,2.tbz
runCommand=pkg_add /mnt/All/unzip-6.0_1.tbz
runCommand=pkg_add /mnt/All/syslog-ng-3.3.5_1.tbz
runCommand=pkg_add /mnt/All/cciss_vol_status-1.10.tbz
runCommand=pkg_add /mnt/All/compat6x-amd64-6.4.604000.200810_3.tbz
runCommand=pkg_add /mnt/All/dmidecode-2.11.tbz
runCommand=pkg_add /mnt/All/pcre-8.31.tbz
runCommand=pkg_add /mnt/All/mcelog-1.0.p2.tbz
runCommand=pkg_add /mnt/All/openjdk6-b25_1.tbz
runCommand=pkg_add /mnt/All/net-snmp-5.7.1_7.tbz

#Clean up and reboot
runExtCommand=umount ${FSMNT}/mnt
runExtCommand=umount ${FSMNT}/dev
runCommand=shutdown -r now


Notes

1. The package install its some hoop jumping but it works. I hope that
Kriss More with add a macro to handle this in the future. I would like
it use to PKG_PATH to make this simpler.
2. The installed FreeBSD originally came from the fbsd-release.txz on
the pc-bsd mirrors however you can provide you own . Work is being
done to make this macro use the FreeBSD tar
balls provided on the install media . That may make it into
9.1-RELEASE but I doubt it.

Thanks to Kriss More for all his help.


-- 
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)

[Mark Linimon]

On Fri, Oct 26, 2012 at 09:34:20AM -0700, David O'Brien wrote:
> (there are no pre-build packages for 10-CURRENT).

Please see the first two entries on:

  http://pkgbeta.freebsd.org/

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Felder]

On Mon, 01 Oct 2012 15:00:40 -0500,  wrote:



Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 5  
ee 60 16 0 1 0 0
Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI  
Status Error

Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy
Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): Retrying command
Sep 21 02:18:44 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 3  
ef 42 51 0 1 0 0
Sep 21 02:18:44 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI  
Status Error

Sep 21 02:18:44 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy
Sep 21 02:18:44 backups kernel: (da1:mpt0:0:1:0): Retrying command
Sep 21 02:18:48 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 3  
ef 64 51 0 1 0 0
Sep 21 02:18:48 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI  
Status Error

Sep 21 02:18:48 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy
Sep 21 02:18:48 backups kernel: (da1:mpt0:0:1:0): Retrying command
Sep 21 02:18:49 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 3  
ef 66 51 0 1 0 0
Sep 21 02:18:49 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI  
Status Error

Sep 21 02:18:49 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy
...
Sep 21 05:06:18 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0  
41 f3 94 99 0 1 0 0
Sep 21 05:06:18 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI  
Status Error

Sep 21 05:06:18 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy
Sep 21 05:06:18 backups kernel: (da1:mpt0:0:1:0): Retrying command



Sometimes you'll see this before a crash, but not every time.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

MDB ("Memory-Mapped Database"), a read-optimized database library

[Mark Blackman]

Hi,

I wonder if this is an interesting library for 
FreeBSD for some userland applications. Perhaps an 
embedded app running on very low end hardware might 
benefit. Interesting use of an old idea in any case.

http://www.openldap.org/pub/hyc/mdm-slides.pdf

- Mark
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Saad]

On Sep 15, 2012, at 11:36 AM, Mark Felder  wrote:

> On Fri, 14 Sep 2012 20:37:40 -0500, Mark Saad  wrote:
> 
>> How do you have suj on 8.3 ? Are you using a patch ?
> 
> I don't have suj on 8.3

I misread the prior emails 

> 
>> Also can you retest 9 with the following 
>> sysctlkern.timecounter.hardware=Acpi-fast
> 
> Yes, I'll attempt that as soon as possible. We're under a tight deadline to 
> migrate critical resources off of VMWare now so I don't know how soon I can 
> test.
> 
>> Also in esxi what setup options do you have for the vm's ?
> 
> I'm not sure what ones I have off the top of my head, but VMWare support has 
> previously poured over ever option to make sure nothing was misconfigured.
> 

It's not that I doubt that , in my experience their support is not equipped to 
answer questions that don't start with " in my windows vm I have this issue 
..." 

>> Lastly do you have esxi setup to talk to a ntp server ? If so can you 
>> confirm that  it's working ? I mean the esxi host not the vm .
> 
> Yes, and yes. We've got a reliable NTP infrastructure at work and ESXi is 
> definitely using it.

Just checking this can cause odd issues . 

What hardware is the esxi host server ? What are you using for the vm disks? Is 
the storage pool on local disks , iscsi , fiber channel , or nfs .  

---
Mark saad | mark.s...@longcount.org

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

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Felder]

On Fri, 14 Sep 2012 20:37:40 -0500, Mark Saad   
wrote:



How do you have suj on 8.3 ? Are you using a patch ?


I don't have suj on 8.3

Also can you retest 9 with the following  
sysctlkern.timecounter.hardware=Acpi-fast


Yes, I'll attempt that as soon as possible. We're under a tight deadline  
to migrate critical resources off of VMWare now so I don't know how soon I  
can test.



Also in esxi what setup options do you have for the vm's ?


I'm not sure what ones I have off the top of my head, but VMWare support  
has previously poured over ever option to make sure nothing was  
misconfigured.


Lastly do you have esxi setup to talk to a ntp server ? If so can you  
confirm that  it's working ? I mean the esxi host not the vm .


Yes, and yes. We've got a reliable NTP infrastructure at work and ESXi is  
definitely using it.

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

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Saad]

On Sep 14, 2012, at 8:48 AM, Mark Felder  wrote:

> Hi Mark,
> 
> Here's the output of our VMs running on ESXi 4.1u1
> 
> FreeBSD 7.4:
> # sysctl kern.timecounter.choice
> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100)
> # sysctl kern.timecounter.hardware
> kern.timecounter.hardware: ACPI-safe
> 
> FreeBSD 8.3:
> # sysctl kern.timecounter.choice
> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100)
> # sysctl kern.timecounter.hardware
> kern.timecounter.hardware: ACPI-safe
> 
> FreeBSD 9.0:
> # sysctl kern.timecounter.choice
> kern.timecounter.choice: TSC(1000) i8254(0) ACPI-fast(900) dummy(-100)
> # sysctl kern.timecounter.hardware
> kern.timecounter.hardware: TSC
> 
> 
> Note that both 8.3 and 9.0 crash, while 7.4 does not.

How do you have suj on 8.3 ? Are you using a patch ? Also can you retest 9 with 
the following sysctl

kern.timecounter.hardware=Acpi-fast 

Also in esxi what setup options do you have for the vm's ?

Lastly do you have esxi setup to talk to a ntp server ? If so can you confirm 
that  it's working ? I mean the esxi host not the vm . 


---
Mark saad | mark.s...@longcount.org 

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

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Felder]

Hi Mark,

Here's the output of our VMs running on ESXi 4.1u1

FreeBSD 7.4:
# sysctl kern.timecounter.choice
kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100)
# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-safe

FreeBSD 8.3:
# sysctl kern.timecounter.choice
kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100)
# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-safe

FreeBSD 9.0:
# sysctl kern.timecounter.choice
kern.timecounter.choice: TSC(1000) i8254(0) ACPI-fast(900) dummy(-100)
# sysctl kern.timecounter.hardware
kern.timecounter.hardware: TSC


Note that both 8.3 and 9.0 crash, while 7.4 does not.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Saad]

---


On Sep 13, 2012, at 7:45 PM, Mark Felder  wrote:

> Changing timer source has not been tested. It doesn't crash in 7.x, so did 
> something timer related change in 8.x?
> 

Mark
  Yes the time counter choice priority changed , in 8 favoring higher precision 
hardware like hpet over acpi-fast/safe . I am not sure why or when thus was 
done; or if this is a side effect of another change. Interestingly 
centos/rhel/suse has made similar changes and VMware has odd issues with them 
as well. 

Can you boot up a 7 environment and get us the value sysctl kern.timecounter . 
Then get that from an a 8 and 9 environment . Then if the 7 environment uses a 
different time counter can you try using that value on your crashing setup and 
report back what the result is . 

---
Mark saad | mark.s...@longcount.org

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

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Felder]

Changing timer source has not been tested. It doesn't crash in 7.x, so did 
something timer related change in 8.x?

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

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Saad]

---


On Sep 13, 2012, at 5:13 PM, Andriy Gapon  wrote:

> on 13/09/2012 22:57 Mark Felder said the following:
>> On Thu, 13 Sep 2012 11:28:15 -0500, Kurt Lidl  wrote:
>> 
>>> Isn't this what you want?
>>> 
>>> http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html
>>> 
>>> -Kurt
>> 
>> Interesting -- it looks like that's an option on ESX as well. The only 
>> question
>> is: what do I do with that? It's going to give me the debugging entire VM, 
>> not
>> the kernel inside. Without being a VMWare developer I imagine its data will 
>> be a
>> bit useless :-(
> 
> No, gdb stub is for debugging what is running inside the VM.
> E.g. look here for an example of how to do that with qemu:
> http://andriygapon.wikispaces.com/QemuSetup
> VMWare with gdb stub enabled should not be any different.
> 
> -- 
> Andriy Gapon
> _


Mark did you try changing the time counter choice sysctl from hpet to 
Acpi-safe/fast or tsc ?  In esx 4.1 an newer using hpet timers causes issues 
for bsd and linux vms in some cases . 

The sysctl is kern.timecounter.choice . This sounds like another VMware issues 
I have seen and read about . See this post 
http://forums.freebsd.org/archive/index.php/t-32104.html

---
Mark saad | mark.s...@longcount.org

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

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Felder]

On Thu, 13 Sep 2012 11:28:15 -0500, Kurt Lidl  wrote:


Isn't this what you want?

http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html

-Kurt


Interesting -- it looks like that's an option on ESX as well. The only  
question is: what do I do with that? It's going to give me the debugging  
entire VM, not the kernel inside. Without being a VMWare developer I  
imagine its data will be a bit useless :-(

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

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Felder]

On Thu, 13 Sep 2012 10:11:28 -0500, Andriy Gapon  wrote:


Just curious - does VMWare provide a remote debugger support (gdb stub)?


I'm not aware of one. What I have been able to successfully do is break  
into the debugger during the hang but the info I've posted so far has not  
been relevant to anyone. I'm hoping someone on the core team will  
eventually be able to follow my guide and figure out what went wrong.

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

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Felder]

On Wed, 12 Sep 2012 14:20:26 -0500, John Baldwin  wrote:


Are you still seeing this, and if so can you get a crashdump?  Also, I'm
curious if you only see this with SUJ or if plain UFS+SU works fine?


The crash on demand right now is producable on 8.x and 9.x, so SUJ isn't a  
requirement. Also, there is no crashdump available. The OS just hangs and  
stops taking input. There's no panic or coredump or anything of the like.  
You just have to nuke the VM and re-boot it back up.


And for the record we can't reproduce this crash in Xen...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Replacing BIND with unbound

[Mark Blackman]

On 20 Aug 2012, at 10:12, Doug Barton  wrote:

> On 08/20/2012 01:55, Bjoern A. Zeeb wrote:
> 
>> We will continue to reject this until there are more firm plans,
>> proper documentation on the security support side, which I cannot
>> remember Simon got an answer for.
> 
> I gave a clear answer. If there are any pieces missing it's up to Simon
> to follow up with Dag-Erling.


>> I continue to say that I am not willing to trade one for another
>> for the sake of just changing the name.
> 
> Have you seriously not been paying attention to the numerous reasons why
> BIND in the base is no longer a good fit?

Perhaps bunging together a quick wiki-page to point busier individuals
at would be handy?

- Mark
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: How to diagnose system freezes?

[Mark Saad]

On Tue, Jul 31, 2012 at 11:14 PM, Yuri  wrote:
> On 07/31/2012 17:50, Mark Saad wrote:
>>
>> Yuri
>>Install sysutils/mcelog and try running the example included . While
>> not a complete definitative hardware test it can report other hardware
>> issues that memtest86+ misses and it can be run on line in multiuser mode
>> and via cron .
>
>
> Thanks for suggesting this. I have a question, however. Let's say 'mcelog
> --daemon' runs and encounters some MCE and logs it. Wouldn't this record be
> lost during the subsequent ungraceful (poweroff) reboot? Nonfatal MCEs, if
> any, will stay but what about the fatal one?
>

Daemon mode does not work on FreeBSD , and on most if not all linux
distros it runs via cron.

In this example you can have it write the logged results via syslog
and hopefully you should be able to review them.

/usr/local/bin/mcelog --ignorenodev --filter --no-dmi --syslog

or

/usr/local/bin/mcelog   --no-dmi > /var/log/mce.log

Now that being said , when mcelog reports an error , it continuously
reports the error, each time mcelog is run,  power cycling did not
clear the mcelog .





-- 
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: How to diagnose system freezes?

[Mark Saad]

On Jul 31, 2012, at 8:29 PM, Julian Elischer  wrote:

> On 7/31/12 5:02 PM, Yuri wrote:
>> One of my 9.1-BETA1 systems periodically freezes. If sound was playing, it 
>> would usually cycle with a very short period. And system stops being 
>> sensitive to keyboard/mouse. Also ping of this system doesn't get a response.
>> I would normally think that this is the faulty memory. But memory was 
>> recently replaced and tested with memtest+ for hours both before and after 
>> freezes and it passes all tests.
>> One out of the ordinary thing that is running on this system is nvidia 
>> driver. But the freezes happen even when there is no graphics activity.
>> Another out of the ordinary thing is that the kernel is built for DTrace. 
>> But DTrace was never used in the sessions that had a freeze.
>> 
>> What is the way to diagnose this problem?
> The answer depends on a number of things but an NMI can be useful if you have 
> some way of
> generating them. (some IPMI implementations can allw you to generate them and 
> some motherboards have
> jumpers to allow you to attach a 'nmi-button'.
> 
> The fact that ping is not responsive is important, as that is done at a very 
> low level but
> it may still be alive down there somewhere.
> 
> Make sure you have debugging enabled in your kernel. That will catch quite a 
> few 'hangs'.
> 
> as also mentioned by others... a serial console and DDB may also be useful in 
> some hangs.
> 
> 
> Julian
>> CPU: i7 CPU 920  @ 2.67GHz
>> Memory: 24GB
>> MB: P2T
>> 
>> Yuri
>> 

Yuri
  Install sysutils/mcelog and try running the example included . While not a 
complete definitative hardware test it can report other hardware issues that 
memtest86+ misses and it can be run on line in multiuser mode and via cron . 

---
Mark saad | mark.s...@longcount.org

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

Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)

[Mark Linimon]

On Tue, Jul 17, 2012 at 01:56:33PM -0700, Dave Hayes wrote:
> I've been using FreeBSD since the 90s. My perception (over many
> years of observation) is that the FreeBSD people most able to
> document what exists and how to use it seem to also have the
> greatest resistance to writing any documentation.

I'll just note that over the past ~6 months, the documentation team has
seen a lot of new contributors and new energy.  So from my view, the
situation is improving.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Using mcelog

[Mark Saad]

All
  I wanted to see how users of mcelog were implementing it on FreeBSD . My 
Linux servers tend to run it via cron hourly and dump the results to syslog or 
a local log file . For now I am going to make a similar setup . Does using it 
as a daemon provide anything running it via cron can't ? Are there any options 
to stay away from , Linux only options etc ? Also does anyone know what options 
there are for FreeBSD on sparc ?  

---
Mark saad | mark.s...@longcount.org

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

Re: Replacing BIND with unbound

[Mark Blackman]

On 10 Jul 2012, at 08:12, Doug Barton wrote:

> On 07/09/2012 14:47, Mark Blackman wrote:
>> I never use '-t' with dig. drill *told* me I should use '-t'
>> then completely failed to acknowledge I had done so.
> 
> Have you reported this bug?

Nope, you?

- Mark
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Replacing BIND with unbound

[Mark Blackman]

On 9 Jul 2012, at 23:01, Dag-Erling Smørgrav wrote:

> Mark Blackman  writes:
>> I never use '-t' with dig. drill *told* me I should use '-t' then
>> completely failed to acknowledge I had done so.
>> 
>> Marks-Macbook% drill -t www.google.com
>> [...]
>> ;; WARNING: The answer packet was truncated; you might want to
>> ;; query again with TCP (-t argument), or EDNS0 (-b for buffer size)
> 
> So you got a truncated response and used -t, it didn't help, and drill
> printed the boilerplate warning message that it always prints when it
> gets a truncated response.  I don't know about you, but I would call
> that a cosmetic nit.
> 
> Unless, of course, you had tcpdump running while you did this and it
> turns out that drill sent a UDP request in spite of -t?  It works fine
> (i.e. it uses UDP by default, and TCP when asked to) for me.

Yes, I worked out it was boilerplate for the general condition. A cosmetic
nit that makes me do a double-take on my first usage strikes me as 
rough around the edges. YMMV. drill certainly looks like a drop-in 
replacement for the common case as you suggest. But if it's not called
'dig' and I've never heard of 'drill', I'm unlikely to reach for 'drill',
hence the alias suggestion.  I *had* never heard of 'drill' until
this thread came up.

> FWIW, the reply I got was not truncated.  Perhaps there is a transparent
> DNS proxy somewhere between you and 178.250.72.130 - quite common with
> broadband CPE.

I have detected there is some kind of stealth DNS interception at work
in the past, although I think it's more central than the CPE.

Mark___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Replacing BIND with unbound

[Mark Blackman]

On 9 Jul 2012, at 22:37, Dag-Erling Smørgrav wrote:

> Mark Blackman  writes:
>> my DNS resolution is broken, so my ports can't download any tarballs. 
>> In this case, I reach for dig to see which part of the DNS resolution
>> chain is failing me. 
>> 
>> At the bare minimum, 'dig' should be an alias for 'drill', which I have 
>> to say isn't working brilliantly for me on OS X. It suggests I use '-t' 
>> and then keeps suggesting I use '-t' even when I do use it.
>> 
>> drill feels a bit rough around the edges to me.
> 
> This reminds me of the (probably apocryphal) American grade school
> teacher who complained that the metric system was so inexact; for
> instance, a meter is _approximately_ a yard, a kilometer is
> _approximately_ two thirds of a kilometer, etc.
> 
> By which I mean, of course, that you are blaming drill not for its own
> shortcomings, but for those of the wrapper you use to _approximate_ dig
> with drill.
> 
> The -t option doesn't mean the same for drill as for dig.  A proper dig
> wrapper for drill would have to translate one to the other.  However,
> you should never need the -t option when using dig; I suspect that it
> exists only for people who are so used to host that they want to use the
> same command line except for s/host/dig/.

I never use '-t' with dig. drill *told* me I should use '-t'
then completely failed to acknowledge I had done so.

Marks-Macbook% drill -t www.google.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 14583
;; flags: qr rd ra ; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; www.google.com.  IN  A

;; ANSWER SECTION:
www.google.com. 44089   IN  CNAME   www.l.google.com.
www.l.google.com.   147 IN  A   173.194.67.106
www.l.google.com.   147 IN  A   173.194.67.147
www.l.google.com.   147 IN  A   173.194.67.104
www.l.google.com.   147 IN  A   173.194.67.105
www.l.google.com.   147 IN  A   173.194.67.103
www.l.google.com.   147 IN  A   173.194.67.99

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 34 msec
;; SERVER: 178.250.72.130
;; WHEN: Mon Jul  9 22:46:13 2012
;; MSG SIZE  rcvd: 148

;; WARNING: The answer packet was truncated; you might want to
;; query again with TCP (-t argument), or EDNS0 (-b for buffer size)


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

Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)

[Mark Blackman]

On 9 Jul 2012, at 22:01, Doug Barton wrote:

> On 07/09/2012 06:45, Mark Blackman wrote:
> 
>> Indeed, 'dig' and 'host' must be present and working as expected 
>> in a minimally installed system.
> 
> So if you don't like the versions that get imported, install bind-tools
> from ports.

my DNS resolution is broken, so my ports can't download any tarballs. 
In this case, I reach for dig to see which part of the DNS resolution
chain is failing me. 

At the bare minimum, 'dig' should be an alias for 'drill', which I have 
to say isn't working brilliantly for me on OS X. It suggests I use '-t' 
and then keeps suggesting I use '-t' even when I do use it.

drill feels a bit rough around the edges to me.

- Mark



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

Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)

[Mark Blackman]

On 9 Jul 2012, at 08:34, Avleen Vig wrote:

> 
> Agreed. The idea of a "minimally functional system" itself might be
> flawed. Do you consider having `dig` and `host` essential in a
> minimally functioning system? I do.
> It's pretty f'king hard to resolve problems with installing the
> bind-utils port, if you don't know how to test your DNS :-)
> 
> The issue is also one of barrier-to-entry. By removing `dig` and
> `host`, I think we're making things unnecessarily more difficult for
> people who don't *know* FreeBSD. `dig` and `host` a universally
> standard tools for doing DNS lookups. Taking them away in base to
> replace them with something else just seems like something that won't
> really *help* users.

Indeed, 'dig' and 'host' must be present and working as expected 
in a minimally installed system.

- Mark


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

Re: Pull in upstream before 9.1 code freeze?

[Mark Felder]

On Thu, 05 Jul 2012 13:51:25 -0500, Matthew Seaman  
 wrote:



AFAIK, no
operating system has a stub resolver the capability to validate DNSSEC.


Yeah, I was sort of hinting at that :-)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Pull in upstream before 9.1 code freeze?

[Mark Felder]

On Thu, 05 Jul 2012 11:05:42 -0500, Damien Fleuriot  wrote:


Using a third-party's name servers is not an option


And how can you trust that your port 53 TCP/UDP traffic isn't being  
redirected and you're talking to the real root servers? I think you're  
being a bit too paranoid...

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

Re: Pull in upstream before 9.1 code freeze?

[Mark Felder]

On Tue, 03 Jul 2012 07:39:34 -0500, Dag-Erling Smørgrav  wrote:


I'm willing to import and maintain unbound (BSD-licensed validating,
recursive, and caching DNS resolver) if you remove BIND.


My only issue is that unbound is still a relatively young project  
(released 2007) and rapidly evolving. Unless the FreeBSD releases really  
pick up the pace it might be worse to have an older version in base. Just  
read the changelogs for the last year and you'll see what I mean.

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

Re: Pull in upstream before 9.1 code freeze?

[Mark Felder]

On Tue, 03 Jul 2012 07:39:34 -0500, Dag-Erling Smørgrav  wrote:



I don't think there will be as much whinging as you expect.  Times have
changed.


Agreed; if we need DNS in base (really, why?) then unbound+nsd are prime  
candidates, but they're healthily maintained in ports...soo... no real  
advantage.

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

Re: [CFC/CFT] large changes in the loader(8) code

[Mark Felder]

On Tue, 26 Jun 2012 12:37:11 -0500, John Baldwin  wrote:


I'm
hesitant to encourage the use of this as I do think putting GPT inside  
of a

gmirror violates the GPT spec.


I personally think this use case is a bit ... odd, anyway.

I have only request to those that manage GPT/GEOM/etc -- as I'm used to  
doing multiple mdadm RAID components on Linux for maximum flexibility,  
using gmirror upon multiple GPT partitions upon the same physical device  
is OK with me. My only complaint is that recovery is very, very stupid. We  
should by default detect and only rebuild ONE gmirror device at a time on  
the same physical provider. You get nothing but a smokin' angry head if  
you allow multiple to rebuild at the same time because it's fighting over  
sequential writes all the way across the platters. It would also be nice  
if gmirror rebuild could also be detected by fsck and fsck could either  
hold off or gmirror could be paused until a consistent filesystem state  
exists. It's probably best for the background fsck to go first so you can  
get the system up and running, but then when it's finished gmirror should  
continue.


Otherwise I have no issues with gmirror -- it does exactly the job I need  
it to.

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

Re: MAGIC with HP KVM - someone will help?

[Mark Felder]

On Mon, 25 Jun 2012 09:38:01 -0500, Atte Peltomäki   
wrote:



If it's any consolation, I've used other brand KVM switches as well and
the only one I've found quite reliable were Raritan and those cost an
arm and a leg.


raritan userstation $65.00
http://www.ebay.com/itm/Raritan-Paragon-II-P2-UST-IP-CAT5-KVM-Keyboard-Video-Mouse-User-Station-/150743344570?pt=US_KVM_Switches_KVM_Cables&hash=item231900e5ba

10 dongles $50.00
http://www.ebay.com/itm/LOT-of-10-NEW-Raritan-Paragon-II-KVM-CIM-P2CIM-PS2-Computer-Interface-Module-/221042459695?pt=COMP_EN_Hubs&hash=item337728442f



We use these at work, as well as the daisy-chain versions of this line and  
they work quite well.

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

Re: reason for "magic" crashes.

[Mark Felder]

Have you proven beyond reasonable doubt that there is no filesystem  
corruption or silent filesystem corruption due to bad hardware?

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

Re: MAGIC with HP KVM - someone will help?

[Mark Felder]

On Wed, 20 Jun 2012 01:14:09 -0500, Wojciech Puchar  
 wrote:


As this KVM have PS/2 connectors to keyboard and mouse i added USB to  
dual-PS/2 converter.


http://geekhack.org/showwiki.php?title=PS2-to-USB+adapters


You probably have a ps/2 converter that's known to be super buggy
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Replacing rc(8) (Was: FreeBSD Boot Times)

[Mark Linimon]

On Wed, Jun 20, 2012 at 04:17:52PM +0300, Vitaly Magerya wrote:
> The last time concurrent rc patches where proposed I measured boot time
> on my laptop (running 8.2-RELEASE i386 IIRC): out of 45 seconds from
> power on to login prompt, 20-25 where spent in rc, and parallel
> execution of it shaved off 7 seconds from boot time.

OK, I stand corrected.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Replacing rc(8) (Was: FreeBSD Boot Times)

[Mark Felder]

On Wed, 20 Jun 2012 04:27:09 -0500, Fernando Apesteguía  
 wrote:



Also, in embedded systems, boot time is an important factor.


If you're designing a very specific embedded product based on FreeBSD why  
aren't you writing your own startup system? Why would anyone expect a  
general purpose "out of the box" OS to excel in a highly optimized  
embedded environment?

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

Re: Replacing rc(8) (Was: FreeBSD Boot Times)

[Mark Linimon]

On Tue, Jun 19, 2012 at 06:45:13PM -0400, Richard Yao wrote:
> That is already done in Gentoo FreeBSD, or do you want me to do the
> work for you to integrate OpenRC in the base system?

We want you to do the work to prove that it is an improvement.  Otherwise
it's "just another claim."

You seem to be missing a couple of principles here, the most important
of which is "first, do no harm."  FreeBSD has as one of its underlying
principles not to violate POLA (Principle Of Least Astonishment.)  The
corollary is that we don't replace code unless we're convinced (not just
told) that the replacement is a better solution.

If this makes FreeBSD more conservative than the way other OSes do
things, so be it.

I'm not trying to be harsh here.  What I'm saying is that the burden
of proof is on the person making the claims "it's better" to demonstrate
that it's so.

Otherwise, there are a zillion PRs with patches already in the database
for committers to pick up and work on.

> I already have OpenRC in Gentoo FreeBSD. Taking the time to integrate
> OpenRC into FreeBSD would be an inefficient use of my time. Not only
> would I fail to gain any improvements on my systems, but I would divert
> development time from things that do benefit me.

Then I expect the situation to remain unchanged.

fwiw, from previous discussions on FreeBSD boot time, ISTR that there
are other places where more time is spent.  Some analysis to prove that
indeed the rc subsystem is the dominant term would be a good starting
place.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Upcoming release schedule - 8.4 ?

[Mark Saad]

So what , this fell on deaf ears or was it a horridly bad idea ?
Anyone care to share ?

On Thu, Jun 14, 2012 at 5:12 PM, Mark Saad  wrote:
> All
>  I have an partial solution to this issue I was thinking about this on
> my morning train ride, so its a bit bumpy.
>
> Here are my solutions they are not complete but I think its a good start.
>
> 1. When official errata and security updates hit the tree . Providing
> updated install media could be step one . Maybe rebuild install media
> periodical say every 3 months, if it warrants it.
>
> 2. Change FreeBSD-update to allow you to select what updates you want,
> and make it work for stable. Simply put think "freebsd-update fetch
> stable kernel" or " freebsd-update fetch release base"
>
> 3. Change FreeBSD-update  to tweak a library so the -pN level is not
> hardcoded into the kernel at compile time. Currently FreeBSD's patch
> or "p level -pN " is a newvers.sh function .
>
> 4. Publish a longer time line for future releases and make it easier
> to find.  While ken smith's email about the 9.1-RELEASE time line was
> a good start , for 9.1,I feel that a short general time line on
> http://www.freebsd.org/releases/ would do a world of good for people
> want to know whats up next and when can I expect it. It does not need
> to be exact just a rough estimate.
>
> The sum total of all of this , in my eyes, is when updated drivers ( I
> know its a still a wish and not reality ) , bug fixes , security
> updates are released , new installs done around that time will start
> out with all of the good bits. Secondly when new updates are released
> users can apply base updates and kernel updates to both release and
> stable as needed. Lastly updates released via this new method would be
> easily checked via uname -a  or maybe " freebsd-update show version"
>
>
> Fire away.
>
> ---
>  Mark Saad | mark.s...@longcount.org



-- 
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Upcoming release schedule - 8.4 ?

[Mark Linimon]

On Fri, Jun 15, 2012 at 10:16:30AM +0200, Damien Fleuriot wrote:
> I'm thinking we might jump straight from 8.x to 10 when the time comes,
> I'm really looking forward to Gleb's work on CARP and PF ;)

I don't know why you might think one .0 release would be more mature
than another .0 release.  Maybe I'm misunderstanding.

> There are not many boxes I could try 9.0 on, because they're in
> production with pfsync to conserve client sessions and I'm loath to
> take risks with most of our firewalls.

This is where having one or more systems for development is key.

Installations like yours are in a far better situation to test FreeBSD under
realistic loads than are all but a few of the FreeBSD developers.  I would
urge testing long before the leadup to a .0 release, not afterwards.

Apologies if I'm just repeating myself here, but FreeBSD does not have a
dedicated QA department.  We are reliant on our users to test in real-
world conditions.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Upcoming release schedule - 8.4 ?

[Mark Saad]

All
 I have an partial solution to this issue I was thinking about this on
my morning train ride, so its a bit bumpy.

Here are my solutions they are not complete but I think its a good start.

1. When official errata and security updates hit the tree . Providing
updated install media could be step one . Maybe rebuild install media
periodical say every 3 months, if it warrants it.

2. Change FreeBSD-update to allow you to select what updates you want,
and make it work for stable. Simply put think "freebsd-update fetch
stable kernel" or " freebsd-update fetch release base"

3. Change FreeBSD-update  to tweak a library so the -pN level is not
hardcoded into the kernel at compile time. Currently FreeBSD's patch
or "p level -pN " is a newvers.sh function .

4. Publish a longer time line for future releases and make it easier
to find.  While ken smith's email about the 9.1-RELEASE time line was
a good start , for 9.1,I feel that a short general time line on
http://www.freebsd.org/releases/ would do a world of good for people
want to know whats up next and when can I expect it. It does not need
to be exact just a rough estimate.

The sum total of all of this , in my eyes, is when updated drivers ( I
know its a still a wish and not reality ) , bug fixes , security
updates are released , new installs done around that time will start
out with all of the good bits. Secondly when new updates are released
users can apply base updates and kernel updates to both release and
stable as needed. Lastly updates released via this new method would be
easily checked via uname -a  or maybe " freebsd-update show version"


Fire away.

---
 Mark Saad | mark.s...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Solving the great resource problem

[Mark Felder]

On Thu, 14 Jun 2012 15:23:11 -0500, Dieter BSD   
wrote:




Replacing perfectly good components simply because they
are GPL. The purpose of BSD is supposed to be creating a
great OS, not providing software hoarders with a supply
of free code to abuse.


You realize that companies like Juniper have a huge investment in FreeBSD  
and the less GPL code they have to deal with the better. FYI they give  
back to us with things like code drops and paid developers.

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

Re: Upcoming release schedule - 8.4 ?

[Mark Linimon]

On Thu, Jun 14, 2012 at 10:29:22AM +0200, Damien Fleuriot wrote:
> Whoever said STABLE is no good for production ?
> 
> I used to make us stick to 8.2-RELEASE here at work, but some bugfixes
> are just too important to skip (we're running firewalls and had a
> problem with a CARP bug).

In theory we try our best to keep -STABLE, well, stable in behavior and
not just the API, but in practice any given snapshot of -stable may or
may not have uncaught regressions in it.

I reiterate, the major difference between -stable and -release is a more
thorough QA process for the latter :-)

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Upcoming release schedule - 8.4 ?

[Mark Felder]

On Wed, 13 Jun 2012 16:49:18 -0500, Damien Fleuriot  wrote:



I for one, as a fbsd admin on corporate servers ( read not commiter),  
would dearly like less releases but a more aggressive MFC approach.


Less releases such as less frequent MAJOR releases (7.0, 8.0, 9.0...) or  
less MINOR releases as well? (8.4, 8.5, 9.1...)

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

Re: Upcoming release schedule - 8.4 ?

[Mark Linimon]

On Thu, Jun 14, 2012 at 06:50:34AM +0200, Wojciech Puchar wrote:
> does it matter. cvsup RELENG_8 and you see updates are done constantly.
> just sometime somebody decide to change number :)

The difference is the freeze-and-test work that goes between "random
date" and "release time".  This requires a nontrivial time committment
from both developers and users.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Upcoming release schedule - 8.4 ?

[Mark Linimon]

On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote:
> The only way that this would really work is if there were dedicated
> sustaining engineers working on actively backporting code, testing it,
> committing it, etc.

I'm going to agree with Garrett here.  IMHO we've reached (or surpassed)
the limit of what is reasonable to ask volunteers to commit their spare
time to.  This is doubly true when we have more than one "stable" branch.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Upcoming release schedule - 8.4 ?

[Mark Saad]

I'll share my 2 cents here, as someone who maintains a decent sided
FreeBSD install.

1. FreeBSD needs to make end users more comfortable with using a
Dot-Ohh release; and at the time of the dot-ohh release
a timeline for the next point releases should be made. *

2. Having three supported releases is showing issues , and brings up
the point of why was 9.0 not released as 8.3 ? **

3. The end users appear to want less releases, and for them to be
supported longer .

* A rough outline would do and it should be on the main release page
http://www.freebsd.org/releases/

** Yes I understand that 9.0 had tons of new features that were added
and its not exactly a point release upgrade from 8.2 , however one can
argue that if it were there would be less yelling about when version X
is going to be EOL'd and when will version Y be released.



-- 
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Upcoming release schedule - 8.4 ?

[Mark Linimon]

On Tue, Jun 12, 2012 at 07:08:08PM -0400, Jerry McAllister wrote:
> You sound like the people who can't decide to get something because a
> new version is going to come out sometime before they die.

That may be how it seems to end-users, but as we have heard multiple
times from people who use FreeBSD to help run their businesses, information
about scheduling and support of releases is key to their decisions on when
to upgrade, or even whether to use FreeBSD in the first place.

To them, your characterization is going to sound quite unfair.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: usertime stale at about 371k seconds

[Mark Linimon]

On Wed, Jun 13, 2012 at 12:30:08AM +0400, Andrey Zonov wrote:
> No, I didn't.  I want to fix the problem not just file a PR and wait
> for years.

I do understand your frustration, but we have some new people interested
in picking up and handling src-related PRs, so I see the situation as
improving a bit.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Upcoming release schedule - 8.4 ?

[Mark Linimon]

On Mon, Jun 11, 2012 at 03:38:56PM -0700, John Kozubik wrote:
> I am looking at the upcoming release schedule, and I only see 9.1
> listed - can anyone confirm or deny 8.4 ?

Although I am not on re@, AFAIK the only schedule that is on the table
is the one for 9.1.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD Boot Times

[Mark Saad]

On Jun 11, 2012, at 6:21 PM, Brandon Falk  wrote:

> Greetings,
> 
> I was just wondering what it is that FreeBSD does that makes it take so long 
> to boot. Booting into Ubuntu minimal or my own custom Linux distro, literally 
> takes 0.5-2 seconds to boot up to shell, where FreeBSD takes about 10-20 
> seconds. I'm not sure if anything could be parallelized in the boot process, 
> but Linux somehow manages to do it. The Ubuntu install I do pretty much 
> consists of a shell and developers tools, but it still has a generic kernel. 
> There must be some sort of polling done in the FreeBSD boot process that 
> could be parallelized or eliminated.
> 
> Anyone have any suggestions?
> 
> Note: This isn't really an issue, moreso a curiosity.
> 
> -Brandon
> _

In amd64 builds the system checks it's ram twice . Early in the boot phase 
using a slower method , and latter using a faster SMAP method. In 9.0-RELEASE 
you can disable the early men check via a loader tunable ,  here is a snip it 
from the release notes on 9.0 . It should also be mfc'd to 7, and 8 stable. 

[amd64, i386, pc98] A loader(8) tunable hw.memtest.tests has been added. This 
controls whether to perform memory testing at boot time or not. The default 
value is 1 (perform a memory test).[r224516]

The next it is switch to a modular kernel  this speeds up boot times be 
omitting kernel items you do not need, you can also do this via with a static 
kernel by removing / disabling unused options . Look at the Archives for ha 
hackers there is a ton of info on this. 

Most of the rest of the boot up time is  via init / rc'ng starting an 
configuring things . Right now this is not parallel-ized out the box . Pc-bsd 
has something called fastboot ? I am am not sure how it works but it improves 
load time in their setups . See 
http://lists.pcbsd.org/pipermail/testing/2012-January/006358.html

Other then that, there  are some other things being developed check the FreeBSD 
wiki for a rc.ng management daemon frs or fsr ? 

---

Mark saad | mark.s...@longcount.org


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

Re: FreeBSD Boot Times

[Mark Felder]

They have a lot of manpower and can spend a lot of time replacing the boot  
subsystems and all startup scripts every 2 releases. For FreeBSD it's not  
a big issue as most people don't reboot often. If it's an itch you want to  
scratch you're more than welcome to look into it; that seems to be the way  
a lot of little things get worked on around here.


Unfortunately the new systemd rc system (which is pretty awful) has issues  
of its own including the inability to handle /usr on a separate filesystem  
under certain situations.[1]


I honestly prefer the freebsd startup system and rc.conf. Speed isn't an  
issue for me right now. It's even less obvious if you just use an SSD for  
/.


[1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Felder]

Hi guys I'm excitedly posting this from my phone. Good news for you guys, bad 
news for us -- we were building HA storage on vmware for a client and can now 
replicate the crash on demand. I'll be posting details when I get home to my PC 
tonight, but this hopefully is enough to replicate the crash for any curious 
followers:

ESXi 5
9 or 9-STABLE
HAST 
1 cpu is fine
1GB of ram
UFS SUJ on HAST device
No special loader.conf, sysctl, etc
No need for VMWare tools
Run Bonnie++ on the HAST device

We can get the crash to happen on the first run of bonnie++ right now. I'll 
post the exact specs and precise command run in the PR. We found an old post 
from 2004 when we looked up the process state obtained from CTRL+T -- flswai -- 
which describes the symptoms nearly perfectly.

 http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2004-02/0250.html 

Hopefully this gets us closer to a fix...


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

Re: reverse USB driver - is it possible?

[Mark Felder]

On Mon, 04 Jun 2012 18:51:50 -0500, Daniel O'Connor  
 wrote:


ISTR someone on the lists was talking about a device by http://i-odd.com  
which does what you want.
I found http://renosite.com/ which is a home brew version of the same  
basic idea.


Zalman ZM-VE200 and ZM-VE300 are also what you want. Kind of nice to have  
ISOs on a drive and be able to make it fake a CDROM/DVDROM/BDROM at your  
leisure.

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

Re: SuperPages utilization survey

[Mark Felder]

On Sat, 02 Jun 2012 06:49:18 -0500, Florian Smeets  wrote:


As far as i understand it does at least enable usage of pages up to 4MB,
perhaps someone should teach mysql about the FreeBSD's limits?
If you look at the output i sent, it certainly changes from using no
superpage mappings at all to using them to some degree, if you script
can be trusted


Wow, this is a nice find. If someone were to add a patch for FreeBSD's  
superpages we might be able to get a nice little performance boost with  
little effort. Even the increase to 4MB for now is a welcome improvement.  
I'll make sure to put this in my toolbox

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

Re: SuperPages utilization survey

[Mark Felder]

[/usr/home/feld]# python spsurvey.py
last pid: 54743;  load averages:  0.28,  0.26,  0.24  up 18+07:41:02 
16:22:45

145 processes: 1 running, 144 sleeping
Mem: 828M Active, 845M Inact, 8517M Wired, 174M Cache, 725M Buf, 265M Free
Swap: 4096M Total, 88M Used, 4008M Free, 2% Inuse

Total accounted memory mappings: 23968 MB (6136043 pages)
Memory in superpages: 12941 MB (14 mappings)
+   pid: 26349 (postgres) start: 80280 stop: 8452c6000 (1066 MB)  
tp: ph path:
+   pid: 26351 (postgres) start: 80280 stop: 8452c6000 (1066 MB)  
tp: ph path:
+   pid: 26352 (postgres) start: 80280 stop: 8452c6000 (1066 MB)  
tp: ph path:
+   pid: 26353 (postgres) start: 80280 stop: 8452c6000 (1066 MB)  
tp: ph path:
+   pid: 26374 (postgres) start: 80280 stop: 8452c6000 (1066 MB)  
tp: ph path:
+   pid: 26382 (postgres) start: 80280 stop: 8452c6000 (1066 MB)  
tp: ph path:
+   pid: 26387 (postgres) start: 80280 stop: 8452c6000 (1066 MB)  
tp: ph path:
+   pid: 26388 (postgres) start: 80280 stop: 8452c6000 (1066 MB)  
tp: ph path:
+   pid: 26398 (postgres) start: 80280 stop: 8452c6000 (1066 MB)  
tp: ph path:
+   pid: 44306 (odasrv) start: 80180 stop: 80600 (72 MB) tp:  
df path:
+   pid: 44318 (odasrv) start: 80180 stop: 805c0 (68 MB) tp:  
df path:
+   pid: 53549 (postgres) start: 80280 stop: 8452c6000 (1066 MB)  
tp: ph path:
+   pid: 53932 (postgres) start: 80280 stop: 8452c6000 (1066 MB)  
tp: ph path:
+   pid: 54515 (postgres) start: 80280 stop: 8452c6000 (1066 MB)  
tp: ph path:

Eligible mappings not promoted: 413


Yup, seems like Postgres does a good job of using superpages
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Felder]

So when this hang happens, there never is a real panic. It just sits in a  
state which I describe as like being in a deadlock. How would I go about  
getting a crashdump if it never panics? Is it possible to do the dump over  
a network or something because I don't believe it can write through the  
controller at all.


Also, thank you for the KTR_SCHED tip. This is the type of info I was  
looking for. Unfortunately I've only ever seen this crash once on a kernel  
with debugging enabled. The machine which is currently prepared to do this  
work used to crash a few times a week and now it has 70 days uptime...  
however, it is an example of a machine with mpt0 and em0 sharing an IRQ so  
I might be able to trigger it using Dane's method.


$ vmstat -i
interrupt  total   rate
irq1: atkbd0 392  0
irq6: fdc0 9  0
irq14: ata0   34  0
irq18: em0 mpt0   1189748491218
cpu0: timer   2174263198400
Total 3364012124619


I'm doing my best to get you guys the info you need, but this is one heck  
of a Heisenbug...

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

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Felder]

On Wed, 30 May 2012 12:17:07 -0500, John Baldwin  wrote:



Humm, can you test it with 2 CPUs?



We primarily only run with 1 CPU. We have seen it crash on multiple CPU  
VMs. Also, Dane Foster appeared to have been using multiple CPUs in his  
video transcoding VMs.


Unfortunately I can't give you more information at the moment. I'm working  
with Dane to compile easy to follow steps that recreate this failure. I  
have not been successful in getting this to crash on demand in my  
environment, but Dane has so we're trying to recreate his.

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

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Felder]

On Wed, 30 May 2012 10:06:13 -0500, John Baldwin  wrote:



Do you only have one CPU in this VM?  If not, do you know which threads
the other CPUs were running (e.g. do you have ps7.png, etc.)?


correct, only one CPU in the VM
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: nvidia-driver-295.49 is highly unstable

[Mark Felder]

On Sun, 27 May 2012 11:46:23 -0500,  wrote:

After the recent system upgrade that brought nvidia-driver-295.49 my  
system began to malfunction.
Xorg randomly freezes and gets to 100% CPU (in kde4), switching back  
from the black terminal takes 30 seconds, some windows don't repaint  
while windows effects are on, etc.

Switching back to 295.05.09 from Feb 11, 2012 fixed the problem.

9400GT

I can't believe this is only my problem. I think the version should be  
rolled back until the problem is fixed.




Hmmm I think this is exactly my problem. My desktop at home is working  
fine, but it's a 4xx and my work machine is a 9xxx. I honestly thought it  
was a flash problem because it seems to happen most on pages that have  
flash content.

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

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Mark Felder]

On Wed, 23 May 2012 17:30:40 -0500, Adrian Chadd   
wrote:



Hi,

can you please, -please- file a PR? And place all of the above
information in it so we don't lose it?



I'd be glad to post a PR and assist in helping to get it permanently  
fixed. I certainly don't want this data to get lost and honestly our  
business uses FreeBSD on VMWare so much that we really need a permanent  
fix as much as anyone else :-)


The reason I've hesitated to post a PR so far is that I didn't have any  
truly useful or concrete evidence of where the problem lies. After Dane  
Foster contacted me and told me he could recreate the crash on demand with  
his workload it was easier to narrow things down. The suggestion that it  
was an interrupts issue (by possibly Bjoern Zeeb?) and Dane's discovery  
that his crashes ceased when em0 and mpt0 share an IRQ, but em0 is  
completely unused was starting to prove there is some strong evidence here  
in favor of the interrupts issue.


Dane, what's the status on your end? Has your fix still been successful?  
Is it also stable if you simply set hint.mpt.0.msi_enable="1" ?



Thanks!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: ARM + CACHE_LINE_SIZE + DMA

[Mark Tinguely]

On Mon, May 21, 2012 at 11:20 AM, Ian Lepore
 wrote:
> On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote:
>> On Thu, May 17, 2012 at 10:07 PM, Ian Lepore
>>  wrote:
>> > On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote:
>> >> Hi,
>> >>
>> >> I'm working on DMA bus implementation for ARM11mpcore platform. I've
>> >> looked at implementation in ARM tree, but IMHO it only works with some
>> >> assumptions. There is a problem with DMA on memory block which is not
>> >> aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent.
>> >>
>> >> Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE.
>> >> Then first cache line associated with the buffer can be divided into
>> >> two parts, A and B, where A is a memory we know nothing about it and B
>> >> is buffer memory. The same stands for last cache line associatted with
>> >> the buffer. We have no problem if a memory is coherent. Otherwise it
>> >> depends on memory attributes.
...

> My suggestion of making a temporary writable mapping was the answer to
> how to correctly change memory attributes on a page which is in use, at
> least in the existing code, which is for a single processor.
>
> You don't need, and won't even use, the temporary mapping.  You would
> make it just because doing so invokes logic in arm/arm/pmap.c which will
> find all existing virtual mappings of the given physical pages, and
> disable caching in each of those existing mappings.  In effect, it makes
> all existing mappings of the physical pages DMA_COHERENT.  When you
> later free the temporary mapping, all other existing mappings are
> changed back to being cacheable (as long as no more than one of the
> mappings that remain is writable).
>
> I don't know that making a temporary mapping just for its side effect of
> changing other existing mappings is a good idea, it's just a quick and
> easy thing to do if you want to try changing all existing mappings to
> non-cacheable.  It could be that a better way would be to have the
> busdma_machdep code call directly to lower-level routines in pmap.c to
> change existing mappings without making a new temporary mapping in the
> kernel pmap.  The actual changes to the existing mappings are made by
> pmap_fix_cache() but that routine isn't directly callable right now.
>
> Also, as far as I know all of this automatic disabling of cache for
> multiple writable mappings applies only to VIVT cache architectures.
> I'm not sure how the pmap code is going to change to support VIPT and
> PIPT caches, but it may no longer be true that making a second writable
> mapping of a page will lead to changing all existing mappings to
> non-cacheable.
>
> -- Ian

We don't want to carry the VIVT cache fixing code to VIPT/PIPT.

I like the x86 approach of marking the page with a cache type
(default/device/uncached/etc). The page mapping routines (for example
pmap_qenter() on a clustered write) will honor that cache type in all
future mappings. It is easy to implement. Other allocations, such as
page tables, can benefit from an attributed allocation too.

I also like having a separate allocator for the sub-page
bus_dmamem_alloc() requests that want uncached buffers. These entries
can stick around for a long time. If we just malloced the entries,
then the other threads that happen to allocate data from the same page
are penalized with uncached buffers too.

--Mark.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"