On Sat, 17 Jul 2010, Rui Paulo wrote:
This doesn't indicate any problem. I suggest you try to figure out what
interrupt is causing this by adding printfs or disabling drivers one by one.
I've no idea where to even begin on something like that. Given that
there are other -current users who
On Sat, 17 Jul 2010, Rui Paulo wrote:
You can try bisecting the faulty revision.
The problem has been going on for months, the primary symptom for a long
time was the nvidia driver, so I stopped using it for a while hoping
that a solution would magically appear. As of the last 6 weeks or so
On Sat, 17 Jul 2010, Kostik Belousov wrote:
Note that intr time most likely come from the interrupt threads chewing
the CPU, not from the real interrupt handlers doing something, and definitely
not due to the high interrupt rate, as your vmstat -i output already shown.
Run top in the mode
On 07/11/10 22:26, Doug Barton wrote:
On 07/11/10 03:28, Alexander Motin wrote:
Doug Barton wrote:
Try backing up to svn r209633 and see if you can boot. What you're
describing is identical to a panic I had starting with the next
revision, also on a Dell laptop.
Please try attached patch
On 07/11/10 23:29, Alexander Motin wrote:
Doug Barton wrote:
On 07/11/10 22:26, Doug Barton wrote:
On 07/11/10 03:28, Alexander Motin wrote:
Doug Barton wrote:
Try backing up to svn r209633 and see if you can boot. What you're
describing is identical to a panic I had starting with the next
On 07/11/10 23:17, Steve Kargl wrote:
On Sun, Jul 11, 2010 at 10:23:35PM -0700, Doug Barton wrote:
Is anyone else seeing this problem? Does anyone have suggestions?
option SCHED_4BSD
I'll give that a try, thanks. :)
Doug
--
... and that's just a little bit of history repeating
On 07/08/10 14:52, Rene Ladan wrote:
On 08-07-2010 22:09, Doug Barton wrote:
On Thu, 8 Jul 2010, John Baldwin wrote:
These freezes and panics are due to the driver using a spin mutex
instead of a
regular mutex for the per-file descriptor event_mtx. If you patch the
driver
to change
Howdy,
I use -current on my laptop as my regular X platform, and for the last
few months I've been noticing that interactivity problems have been
getting a lot worse, by which I mean that if I have something running in
the background that is either disk or cpu intensive, anything else I try
to do
On 07/11/10 03:28, Alexander Motin wrote:
Doug Barton wrote:
Try backing up to svn r209633 and see if you can boot. What you're
describing is identical to a panic I had starting with the next
revision, also on a Dell laptop.
Please try attached patch against HEAD.
This worked for me
Try backing up to svn r209633 and see if you can boot. What you're
describing is identical to a panic I had starting with the next
revision, also on a Dell laptop.
Doug
On 07/10/10 00:44, raoul wrote:
Hi all,
since last friday head panic, even with a fresh update (yesterday evening).
i
On Thu, 8 Jul 2010, John Baldwin wrote:
These freezes and panics are due to the driver using a spin mutex instead of a
regular mutex for the per-file descriptor event_mtx. If you patch the driver
to change it to be a regular mutex I think that should fix the problems.
Can you give an
On Mon, 28 Jun 2010, Garrett Cooper wrote:
On Sat, Jun 26, 2010 at 10:50 PM, Doug Barton do...@freebsd.org wrote:
On 06/26/10 13:29, Hans Petter Selasky wrote:
Hi,
Sometimes utilities that are started by devd require libraries outside
/usr/lib. One example is the webcamd utility which
On 06/26/10 13:29, Hans Petter Selasky wrote:
Hi,
Sometimes utilities that are started by devd require libraries outside
/usr/lib. One example is the webcamd utility which is started by devd upon
USB
device insertion. What do you think about the following patch:
--- devd
Howdy,
I tried upgrading from r209351 to r209434 and got a panic related to the
timer stuff while booting. You can see the panic and the backtrace here:
http://people.freebsd.org/~dougb/timer-panic-1.jpg
http://people.freebsd.org/~dougb/timer-panic-2.jpg
On 06/22/10 12:55, Doug Barton wrote:
Howdy,
I tried upgrading from r209351 to r209434 and got a panic related to the
timer stuff while booting. You can see the panic and the backtrace here:
http://people.freebsd.org/~dougb/timer-panic-1.jpg
http://people.freebsd.org/~dougb/timer-panic-2
On 06/22/10 13:10, Alexander Motin wrote:
Doug Barton wrote:
On 06/22/10 12:55, Doug Barton wrote:
Howdy,
I tried upgrading from r209351 to r209434 and got a panic related
to the timer stuff while booting. You can see the panic and the
backtrace here:
http://people.freebsd.org/~dougb
On 06/22/10 14:17, Alexander Motin wrote:
Run `sysctl kern.eventtimer.timer2=i8254`, then after few seconds check
messages to see if system liked this timer (it should fall back
automatically if it's not),
Seems ok. Here is what I got on the console, no error messages in
/var/log/all.
sysctl
mav, could this be related to r209371?
Doug
On 06/21/10 11:16, FreeBSD Tinderbox wrote:
TB --- 2010-06-21 16:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-06-21 16:15:00 - starting HEAD tinderbox run for i386/i386
TB --- 2010-06-21 16:15:00 - cleaning the object tree
On 06/21/10 13:59, Alexander Motin wrote:
Doug Barton wrote:
mav, could this be related to r209371?
It is. Fixed. Thanks.
Thank YOU for jumping on it so quickly. :)
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
On 06/20/10 08:47, Alexander Motin wrote:
While this can be done in sysctl.conf, it would be better to do it in
loader.conf to make it applied from the beginning, without on-the-fly
timers change.
You're probably right that for something this fundamental it's better to
do it in loader.conf,
On 06/18/10 11:20, Alex Dupre wrote:
Update: the signer plugin (that requires libassuan) will be removed in
opensc 0.12 release.
Thanks for this update, and thanks to Dima too for clarifying the kdepim
situation. I'm not just making changes willy-nilly. :)
Doug
--
... and that's
[ FYI, this message should have gone to freebsd-po...@freebsd.org ... ]
On 06/17/10 11:20, Kevin Oberman wrote:
2.0.0 should be the preferred version, but its API is incompatible with
the old one. Many ports using libassuan (listed in UPDATING) have not
been updated to support V2, so the
Howdy,
I thought my heat problems were over with this laptop thanks to all the
great suggestions I've received about powerd, no stepping, etc. (I also
propped up both the back and the front to make a nice big air pocket.)
I've always been pretty religious about blowing the dust off the fans
On 6/16/2010 5:05 AM, John Baldwin wrote:
You can reduce the polling interval by changing
hw.acpi.thermal.polling_rate (it is in seconds it seems) to a lower value.
Thanks, I'll give that a try, although with the cleaning I gave it
yesterday I'm hoping to avoid heat problems for a while. :)
On 06/15/10 09:32, Lars Engels wrote:
On Tue, Jun 15, 2010 at 09:25:22AM -0700, Rui Paulo wrote:
On 15 Jun 2010, at 09:17, Lars Engels wrote:
On Tue, Jun 15, 2010 at 09:00:51AM -0700, Rui Paulo wrote:
On 15 Jun 2010, at 08:03, Lars Engels wrote:
The issue is still present in r209168.
(/usr/local/bin/gcc44)
CC = gcc44
CXX = g++44
CPP = cpp44
.endif
What happens when .CURDIR = /usr/src?
i'm now using [...]
I was trying to show you why what you had didn't work...
sorry. i didn't mean to affend you. doug barton already pointed out
that what i had in my make.conf beforehand won't
On 06/15/10 10:24, Alexander Best wrote:
`make -V .CURDIR` in /usr/src returns /usr/src
Thanks. Now:
cd /usr/obj/usr/src
make -V .CURDIR
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of
On 06/14/10 14:30, Rene Ladan wrote:
On 14-06-2010 14:48, John Baldwin wrote:
On Sunday 13 June 2010 11:23:07 pm Doug Barton wrote:
On 06/13/10 19:09, Alan Cox wrote:
On Sun, Jun 13, 2010 at 8:38 PM, Doug Bartondo...@freebsd.org wrote:
On 06/01/10 08:26, John Baldwin wrote:
I've asked
On 06/14/10 19:14, Doug Barton wrote:
Details, I'm running today's -current (r209174) and I've had it up for
4.5 hours already, which is 3 hours longer than I was able to run with
anything 195.22 for months. I've done full normal use which includes
lots of terminals, tbird, firefox, flash, etc
On 06/13/10 15:58, Alexander Best wrote:
hmmm...but i thought during buildworld either
empty(.CURDIR:M/usr/src/*) or
empty(.CURDIR:M/usr/obj/*) should be false. so CC/CXX/CPP should never
actually be set during buildworld or buildkernel.
That depends, are /usr/src and /usr/obj literally
On 06/13/10 16:21, Alexander Best wrote:
`mount -p stat -x /usr/src /usr/obj`:
wow, completely unhelpful. So let me try again. If the /usr/src and
/usr/obj are not literal directories in /usr then the tests you posted
won't work. Given what you've posted so far I strongly suspect that
On 06/01/10 08:26, John Baldwin wrote:
I've asked the driver author if the calls to vm_page_wire() and
vm_page_unwire() can simply be removed but have not heard back yet.
Is there any news on this? I have updated to the latest current so I'm
running the nv driver now, but I'd like to get the
On 06/13/10 19:09, Alan Cox wrote:
On Sun, Jun 13, 2010 at 8:38 PM, Doug Bartondo...@freebsd.org wrote:
On 06/01/10 08:26, John Baldwin wrote:
I've asked the driver author if the calls to vm_page_wire() and
vm_page_unwire() can simply be removed but have not heard back yet.
Is there any
On 06/12/10 08:10, M. Warner Losh wrote:
In message:4c1315f9.6000...@freebsd.org
Doug Bartondo...@freebsd.org writes:
: On 06/11/10 14:18, M. Warner Losh wrote:
: This is building the proper set of tools for the target. It is easy
: to do, and only a couple lines of Makefile foo
On 06/12/10 16:16, M. Warner Losh wrote:
I plan on fixing this problem
That's good news, since I'm obviously too stupid to understand why it
exists. :) I look forward to seeing your solution.
Doug
--
... and that's just a little bit of history repeating.
On 06/11/10 13:35, Ed Schouten wrote:
* M. Warner Loshi...@bsdimp.com wrote:
Except that clang isn't quite disabled when cross-building, due to the
issue I pointed out when the commit went in wrt bsd.own.mk.
MACHINE_ARCH is still amd64 until we start to build the sparc64
binaries, so anything
On 06/11/10 14:18, M. Warner Losh wrote:
This is building the proper set of tools for the target. It is easy
to do, and only a couple lines of Makefile foo in Makefile.inc1
instead of in bsd.own.mk. It is a fairly natural consequence of the
tbemd stuff I have been working on and have started
On 06/10/10 13:31, Mike Jakubik wrote:
How does this differ from a mergemaster -iFU ? That's pretty much as
automated as it can get.
FYI, the -F option is usually only needed once, when switching from cvs
checkout to svn checkout, or vice versa. It won't hurt anything to
combine it with -U,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/10/10 10:46, John Baldwin wrote:
| I've had several folks ask me recently about importing etcupdate
| (http://www.FreeBSD.org/~jhb/etcupdate) into the base system as an alternate
| tool for updating /etc during upgrades. Do folks have any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/10/10 11:18, Julian Elischer wrote:
| It does bring up the question (yet again) if we shouldn't
| have something that is between base and ports..
| the keep base from bloating too much bit to still indicate
| that they are supported.
Julian,
On 6/10/2010 5:28 PM, Julian Elischer wrote:
code in the base tree gets fixed by people making sweeping changes
but things from ports often do not.
Code will either be maintained well, or it will not. I've seen plenty of
stuff in src break, and the src build is often broken by under-tested
On 06/06/10 12:32, Lyndon Nerenberg wrote:
Beyond that, Free is one of the few UNIXen I cannot talk to (or from!)
using Kerberos for things like SSH, rlogin, rdist, etc. We're woefully
behind Solaris, Linux, even Windows, when it comes to integrated
GSSAPI/K5 SSO authentication.
... and it's
On 06/06/10 12:46, Lyndon Nerenberg wrote:
... and it's not going to get any better till someone steps up and
volunteers to improve it. Can we count on you?
I've brought this up at least three times over the past 10(+?) years,
and been blown off every time. So yes, I'm volunteering, again.
On 06/04/10 23:10, Anonymous wrote:
Most ports decide features based on MACHINE_CPU not CPUTYPE. However,
MACHINE_CPU doesn't support non-base compiler and `native' CPUTYPE. Plus
core2 CPUTYPE is silently degraded to nocona/prescott even when it's
supported by underlying compiler. See
On 06/04/10 08:26, Roman Divacky wrote:
Dear current@
On June 9th, we are importing clang/LLVM into FreeBSD HEAD.
Excellent news! :) I am in favor of this, and look forward to a day of
using a FreeBSD system compiled as much as possible with clang.
During the ongoing discussion there were
On 06/04/10 10:44, Andrius Morkūnas wrote:
On Fri, 04 Jun 2010 19:59:15 +0300, Doug Barton do...@freebsd.org wrote:
2. Publish instructions on how to set up a different compiler for ports.
There's really no nice way to do it right now. We'll probably put something
on the wiki page[1
On 06/04/10 10:46, Alexander Best wrote:
src.conf should ALWAYS take priority over make.conf when
buildworld or buildkernel is being run.
Defining the same variables in different contexts is always a recipe for
the dreaded unpredictable results. Even if it were possible to create
the proper
On 06/04/10 11:39, Freddie Cash wrote:
On Fri, Jun 4, 2010 at 10:55 AM, Doug Bartondo...@freebsd.org wrote:
Wouldn't it be great, if /etc/make.conf disappeared completely?
No, since it's useful for things that are common to both src and ports,
and to stuff that is neither.
To be replaced
On 06/04/10 11:28, Andrius Morkūnas wrote:
On Fri, 04 Jun 2010 20:52:32 +0300, Doug Barton do...@freebsd.org wrote:
Sorry I wasn't clear. I'm not talking about compiling ports with clang
(which I also look forward to someday) I'm talking about installing a
version of gcc from ports and using
100% agreement with Mark here.
On 06/03/10 17:19, Mark Linimon wrote:
I'm just catching up with this thread, so apologies if this has already
been pointed out elsewhere.
One of the things that has been discussed w/rt compilers for a while
(not just at the devsummit) was bending our minds
On 06/04/10 17:38, Doug Barton wrote:
On 06/04/10 11:28, Andrius Morkūnas wrote:
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/configuring-ports-gcc.html
Ok, everything in that section seems clear except this in 3.3:
It is possible to completely replace CFLAGS and/or define
On 05/31/10 17:46, Lawrence Stewart wrote:
On 06/01/10 09:25, James R. Van Artsdalen wrote:
[snip interesting history]
I do suggest modifying the FreeBSD build process so that uname -a shows
the compiler and its version for both the kernel and userland.
Reading through this discussion, I
On 05/29/10 03:54, b. f. wrote:
On 5/29/10, Rui Paulorpa...@freebsd.org wrote:
On 29 May 2010, at 05:39, b. f. wrote:
On 5/28/10, Doug Bartondo...@freebsd.org wrote:
On 5/28/2010 4:50 PM, b. f. wrote:
I can't see any problems when using WPA2 with AES on r208606 i386 with
uath(4). I'm
On 05/26/10 09:51, Kostik Belousov wrote:
I did a quick glance over the driver, try this:
http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch
I did not even compiled the patched driver.
Ok, I just tried this with an r208622 kernel and sources, and the system
locks up as soon as I
I am trying to update -current in order to try kib's patch for the
nvidia driver, and the wpi driver won't establish a connection. I'm
using r207134 right now without any problems, but that's a long time
back to try and do a binary search.
I don't see any changes to wpi or wpa_supplicant
On 05/28/10 13:18, Doug Barton wrote:
I am trying to update -current in order to try kib's patch for the
nvidia driver, and the wpi driver won't establish a connection. I'm
using r207134 right now without any problems, but that's a long time
back to try and do a binary search.
I don't see any
On 5/28/2010 4:50 PM, b. f. wrote:
I can't see any problems when using WPA2 with AES on r208606 i386 with
uath(4). I'm updating this machine to r208630 tonight, and if I
encounter problems with the later revision, I'll let you know.
Ok, thanks.
Are
you saying that you experienced problems
On 05/26/10 09:51, Kostik Belousov wrote:
I did a quick glance over the driver, try this:
http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch
I did not even compiled the patched driver.
cc -pipe -g -g -g -DNV_VERSION_STRING=\195.36.15\ -D__KERNEL__ -DNVRM
-O -Werror -D_KERNEL
On 5/27/2010 12:12 PM, Kostik Belousov wrote:
I think you have stale/wrong includes used by the build. I just checked
that driver indeed builds with my patch. vm_page_lock() and vm_page_unlock()
are the macros defined in vm/vm_page.h that are present since first
Kip commit.
As I reported
On 5/26/2010 9:51 AM, Kostik Belousov wrote:
I did a quick glance over the driver, try this:
http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch
I did not even compiled the patched driver.
Kostik,
Thanks for taking a look at this! I sent the following to Alexey
recently in
On 05/05/10 11:56, Alan Cox wrote:
I'm afraid that I would advise waiting a few days. This round of changes
are not yet complete.
Is the coast clear yet? :) I have been holding off on updating -current
due to the SUJ stuff, but that seems to have mostly settled down now, so
I'm hoping that
On 05/08/10 13:36, Alan Cox wrote:
Doug Barton wrote:
On 05/05/10 11:56, Alan Cox wrote:
I'm afraid that I would advise waiting a few days. This round of
changes
are not yet complete.
Is the coast clear yet? :) I have been holding off on updating -current
due to the SUJ stuff
On 05/05/10 10:13, Roman Divacky wrote:
2) mergemaster problems - I have a fix but have not commited it yet
Can you describe the problem, and your proposed fix?
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve
On 05/03/10 06:19, sth...@nethelp.no wrote:
I would vote for decoupling. If I have SU on, then enable journaling,
then disable journaling, I would expect SU to still be on.
Fully agreed. I see no reason why these sould be coupled.
It does not look like it is a prerequisite to have SU enabled
Before I forget, I can't find the key that you signed this message with
on any key servers; FYI.
On 05/03/10 07:16, Mark Atkinson wrote:
I updated a border gateway yesterday from a Feb 23 kernel to a May 2
version kernel/world,
There have been numerous changes to IPv6 related stuff, both in
On 05/01/10 18:10, Jeff Roberson wrote:
When you disable journaling it also disables soft-updates. You need to
re-enable it. I could decouple this. It's hard to say which is the POLA.
I would vote for decoupling. If I have SU on, then enable journaling,
then disable journaling, I would
On 04/25/10 03:23, Alexander Best wrote:
another option would be to have a ata(4)-cam(4)-ata(4) emulation.
What would be the value of doing all of that work as opposed to just
using one of the available options that already work with cam such as
cdrecord?
Doug
--
... and that's
On 04/25/10 00:00, Bruce Cran wrote:
On Sunday 25 April 2010 02:55:16 Doug Barton wrote:
On 04/24/10 17:54, Bruce Cran wrote:
# if_bridge doesn't have a link-local address by default, so add one
ifconfig_bridge0_ipv6=fe80::2%bridge0 prefixlen 64
It's likely that you need to add inet6
On 04/25/10 19:03, Scott Long wrote:
On Apr 25, 2010, at 7:58 PM, Doug Barton wrote:
On 04/25/10 03:23, Alexander Best wrote:
another option would be to have a ata(4)-cam(4)-ata(4)
emulation.
What would be the value of doing all of that work as opposed to
just using one of the available
On 04/24/10 09:42, Pegasus Mc Cleaft wrote:
Hello Hackers Current,
Please don't crosspost. If you're not what list to post to, the
algorithm is: If the question is about a port, or the ports in general,
use freebsd-ports@, otherwise use freebsd-questi...@. This post should
have gone to -ports.
On 04/24/10 17:54, Bruce Cran wrote:
I updated my router to the latest -CURRENT yesterday
Did you run mergemaster after you upgraded? How old/what version of
FreeBSD did you upgrade from?
and now I'm getting an
error on startup from ifconfig saying the the IPv6 addresses I've configured
manner.
More comments below.
On 04/23/10 08:26, Hiroki Sato wrote:
Doug Barton do...@freebsd.org wrote
in 4bcb6a14.5040...@freebsd.org:
do # ifconfig gif0 create
do # ifconfig gif0 up
do
do Your statement is literally true, in this case the network.subr stuff
do has no control
Now we're getting somewhere. :)
On 04/18/10 12:04, Hiroki Sato wrote:
Doug Barton do...@freebsd.org wrote
in 4bca2b55.9000...@freebsd.org:
do I strongly disagree with this because some IPv6
do applications depend on link-local address automatically added on
do cloned interfaces
do
On 04/17/10 10:24, Andrius Morkūnas wrote:
On Sat, 17 Apr 2010 20:07:05 +0300, Dimitry Andric dimi...@andric.com
wrote:
Btw, http://wiki.freebsd.org/BuildingFreeBSDWithClang says to put these
in src.conf, it does not mention make.conf. This is most likely the
correct location, right?
consistent for our users. If after reading this message you still don't
agree with my perspective I would like to suggest that you use the
available dispute resolution mechanism and then we can take it from there.
On 04/17/10 07:39, Hiroki Sato wrote:
Doug Barton do...@freebsd.org wrote
It's generally also a good idea to cc the author of the change just in
case they don't get to their -current mail in a timely manner.
hth,
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of
On 4/16/2010 3:27 PM, Bjoern A. Zeeb wrote:
On Fri, 9 Apr 2010, Doug Barton wrote:
Hi,
first off all it would have been easier to figure a few things out, if
the several different things had been individual commits
I considered that but given that the changes had to happen at the same
On 04/12/10 13:43, Miroslav Lachman wrote:
If you are the only one person responsible for all rc stuff,
I did not mean to imply that in any way. I just wanted to provide a
perspective of one person on the list as to why I haven't commented.
Doug
--
... and that's just a little bit
On 4/12/2010 9:45 AM, Miroslav Lachman wrote:
I have bad experiences with freebsd-rc mailing list - no responses to my
direct e-mails and no responses for PRs (PR sent more than year ago,
direct e-mails 3 month ago without any reaction).
I don't know who is responsible person for rc system
Good news. A post r206419 kernel works as anticipated. Thanks for jumping
on this.
Doug
--
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
Computers are useless. They can only give you answers.
On Wed, 7 Apr 2010, Eir Nym wrote:
All is good in BIND in system, except it depends on ports tree with
various options.
I have to do followed algorithm, to enable these options:
1) make and install base system
2) install needed dependencies from ports tree
There is another step here, enable
Rui,
I updated my kernel to the latest today, and was unable to connect via
wireless. I have a 3945ABG using wpi. I rolled back to r206357 and
everything worked fine. I then rolled forward to r206369 (your rate
control mod + bug fixes and - debugging code) and it stopped working. I
didn't bother
On 04/04/10 22:49, Hiroki Sato wrote:
Doug Barton do...@freebsd.org wrote
in 4bb95564.1070...@freebsd.org:
do On 04/04/10 02:41, Hiroki Sato wrote:
do Kevin Oberman ober...@es.net wrote
doin 20100404053352.e6f751c...@ptavv.es.net:
do
do ob The use of FACILITY_enable in rc.conf
[ snipped ]
On 04/05/10 08:52, Bjoern A. Zeeb wrote:
I have no idea (unless I'll read them) about the guts of various shell
function magic we use to configure interfaces, and I heck do not care
about where it's called autoblah_foo or zigbangbusheek as none of our
users does, so I'll ignore
On 04/04/10 23:01, sth...@nethelp.no wrote:
No, my intension is not to compare IPv4 and IPv6 here. We have never
enable L3 address autoconfiguration without explicit configuration
before. This is reasonable and should be kept for IPv6, too.
Agree 100%. Having IPv6 SLAAC as the default is
going to repeat myself one more time here, and in response to your
other post, and then step back and let others express their opinions.
I'd really like to come to an agreement on how to proceed in the next
couple days.
On 04/04/10 22:49, Hiroki Sato wrote:
Doug Barton do...@freebsd.org wrote
On 04/04/10 22:42, Hiroki Sato wrote:
Doug Barton do...@freebsd.org wrote
in 4bb7e224.6020...@freebsd.org:
If people want to disable IPv6 GUA assignment in per-AF manner, it
should be done by per-AF global knobs for $ifconfig_* because the GUA
assignment involves $ifconfig_* knobs only
Thanks for the reply, it's nice to get other viewpoints involved,
especially from those who have actual working knowledge of IPv6. I'm
going to snip the bits where we agree for ease of reading.
On 04/03/10 22:33, Kevin Oberman wrote:
Date: Sat, 03 Apr 2010 17:49:40 -0700
From: Doug Barton do
On 04/04/10 02:41, Hiroki Sato wrote:
Kevin Oberman ober...@es.net wrote
in 20100404053352.e6f751c...@ptavv.es.net:
ob The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I
ob see no reason not to use them to enable or disable functionality whether
ob it involves a script
On 04/04/10 02:51, sth...@nethelp.no wrote:
No, my intension is not to compare IPv4 and IPv6 here. We have never
enable L3 address autoconfiguration without explicit configuration
before. This is reasonable and should be kept for IPv6, too.
Agree 100%. Having IPv6 SLAAC as the default
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
hrs@ has been doing some great work on bringing IPv6 support up to par
with IPv4, and deserves a lot of credit for that work. Included in those
changes were changes to the traditional semantics of how ipv6_enable
works. That variable was
This is happening at boot time, but not every time. Yesterday's
-current, r206116. core.txt.3 is in freefall:~dougb.
#0 doadump () at pcpu.h:246
246 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0 doadump () at pcpu.h:246
#1 0xc05f754f in boot (howto=260)
at
be configured.
On 04/03/10 04:51, Hiroki Sato wrote:
Doug Barton do...@freebsd.org wrote
in 4bb70e1e.3090...@freebsd.org:
do 1. There should be an ipv6_enable knob to easily turn IPv6 configuration
do on and off when INET6 is in the kernel. I think the value of this kind
do of knob is obvious
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
So first of all, yes Virginia, this was an April Fool's Day joke. To
both those for whom this post created a false sense of despair, and
(perhaps more importantly) to those for whom it created a false sense of
joy, my apologies. :) And for the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Greetings,
SUMMARY
On February 21 I sent a message to freebsd-a...@freebsd.org detailing
the current state of BIND on FreeBSD, and plans for the future. You can
see that message here:
On 03/15/10 17:41, David O'Brien wrote:
I'd rather not introduce yet more special things that have to be done
before invoking newvers.sh.
David,
Trying to understand what you're getting at here. What's your use case
for invoking newvers.sh from the command line? AFAIK it's only every
used as
On 03/15/10 18:34, M. Warner Losh wrote:
In message: 4b9edb05.4020...@freebsd.org
Doug Barton do...@freebsd.org writes:
: On 03/15/10 17:41, David O'Brien wrote:
: I'd rather not introduce yet more special things that have to be done
: before invoking newvers.sh.
:
: David
On 03/09/10 12:14, Li, Qing wrote:
This error was caused by my commit r204902 from yesterday.
Please try patch at
http://people.freebsd.org/~qingli/route.h.diff
This doesn't appear to be committed yet, is it still the best fix?
Doug
--
... and that's just a little bit of
On 03/01/10 10:24, Rui Paulo wrote:
On 1 Mar 2010, at 04:14, Doug Barton wrote:
core.txt.0 is in my home directory on freefall.
Can't see it: No read permission.
Fixed, sorry.
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Loaded symbols for /boot/kernel/wpifw.ko
#0 doadump () at pcpu.h:246
246 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0 doadump () at pcpu.h:246
#1 0xc05f668f in boot (howto=260)
at /usr/local/src/sys/kern/kern_shutdown.c:416
#2 0xc05f6972 in panic (fmt=Variable fmt is
401 - 500 of 865 matches
Mail list logo
