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

Pawel Jakub Dawidek wrote in <20120628230725.gb1...@garage.freebsd.pl>: pj> PS. We are discussing two totally different things here: pj> 1. Is placing GPT on anything but raw disk violates the spec? I can pj>agree that it does and I'm happy with gpart(8) growing a warning. I agree that th

Re: accepting rtadv broken on 9-STABLE, re driver?

Mark Felder wrote in : fe> On Mon, 09 Jan 2012 13:02:24 -0600, Hiroki Sato fe> wrote: fe> fe> > re0 seems to have ACCEPT_RTADV. What is the problem? fe> fe> That's because I haven't rebooted fe> fe> Let's start fresh. fe> fe> The no

Re: accepting rtadv broken on 9-STABLE, re driver?

Mark Felder wrote in : fe> On Sat, 07 Jan 2012 14:23:46 -0600, Hiroki Sato fe> wrote: fe> fe> > It is an unexpected behavior and the flag should be set on all fe> > interfaces. Can you send me your /etc/rc.conf, /etc/sysctl.conf, and fe> > the result of "if

Re: accepting rtadv broken on 9-STABLE, re driver?

Mark Felder wrote in <891fe25c-1560-479f-b855-1713c1c7a...@email.android.com>: fe> Hiroki Sato wrote: fe> > fe> > Is it correct that ACCEPT_RTADV option was enabled on the vboxnet0 fe> > and not on re0, even after setting net.inet6.ip6.accept_rtadv

Re: accepting rtadv broken on 9-STABLE, re driver?

Mark Felder wrote in : fe> I figured I would end up putting that in rc.conf as a temporary fix, fe> but maybe that's just the long term solution. It seems so odd to me fe> that the sysctl change doesn't automatically cause the ACCEPT_RTADV fe> option to show up for re0, but it does for vboxnet0

Re: FIB separation

Vlad Galu wrote in : du> Hello, du> du> A couple of years ago, Stef Walter proposed a patch[1] that enforced du> the scope of routing messages. The general consesus was that the best du> approach would be the OpenBSD way - transporting the FIB number in the du> message and letting the user appl

Re: send-pr

ts/index.html * Problem Report Handling Guidelines http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pr-guidelines/index.html * How to get best results from the FreeBSD-questions mailing list http://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-questions/index.html -- | Hiroki SATO

Re: initstate() on FreeBSD/sparc64

Hiroki Sato <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]>: hrs> I noticed that initstate() caused memory corruption on hrs> FreeBSD/sparc64. I guess this is because lib/libc/stdlib/random.c hrs> assumes "long" is 32-bit long. Some suggested using int32_t

initstate() on FreeBSD/sparc64

Hi, I noticed that initstate() caused memory corruption on FreeBSD/sparc64. I guess this is because lib/libc/stdlib/random.c assumes "long" is 32-bit long. The attached patch works fine on my box, but this is a bit ugly. Could anyone take care of this? -- | Hiroki SAT