Re: Early drop to debugger with DEBUG_MEMGUARD

2013-08-12 Thread David Wolfskill 
On Tue, Aug 13, 2013 at 08:29:44AM +0300, Konstantin Belousov wrote:
> ...
> The r254025 indeed introduced the problem, and Davide pointed out you a
> workaround for the assertion triggering.

Right; I tried one of those -- I hope I got it right...

> Proper fix for the memguard requires a policy of M_NEXTFIT or like, to
> avoid a reuse of the previous allocated range as long as possible.

Ah.

> But, you have some further issue even after the assertion was silenced,
> isn't it ?

Yes; please see
 for a copy
of the message that shows the resulting panic.  (Or see previous
messages i this thread, if that's easier.)  It looks (from my naive
perspective) as if mti_zone hadn't been initialized (properly?  at
all?).

In any case, I remain willing to test, subject to Internet connectivity
flakiness where I am now and other demands on my time.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil men with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpXXik07dJRX.pgp
Description: PGP signature

Re: i386 panic

2013-08-12 Thread Konstantin Belousov 
On Mon, Aug 12, 2013 at 12:43:02PM -0700, Sean Bruno wrote:
> http://people.freebsd.org/~sbruno/10_i386_vmfault.txt
> 
> I can never tell if stuff like this is because I'm not nerfing the
> system RAM correctly or if this is i386 bit-rot.  
> 
> I set hw.physmem="2g" in loader.conf to try and get the system to boot,
> but I don't think I did it right?
> 
> Sean

kernel trap 12 with interrupts disabled
panic: vm_fault: fault on nofault entry, addr: c9f7c000
...
calltrap() at calltrap+0x6/frame 0xc1820c9c
--- trap 0xc, eip = 0xc1820d37, esp = 0xc1820ce8, ebp = 0 ---
end() at 0xc1820d37

First thing is to try to identify what is the code was executing there.
Try to disassemble some amount of instructions before and after the
faulting %eip.


pgpbg0qmz9zwC.pgp
Description: PGP signature

Re: Early drop to debugger with DEBUG_MEMGUARD

2013-08-12 Thread Konstantin Belousov 
On Mon, Aug 12, 2013 at 02:44:35PM -0700, David Wolfskill wrote:
> On Mon, Aug 12, 2013 at 09:10:55AM -0700, Davide Italiano wrote:
> > ...
> > OK, I'm not sure I can make an immediate guess on where's the problem
> > now (without access to my main workstation), so I think you need to
> > wait tomorrow unless someone beats me to the punch. The best I can say
> > is that maybe r254025 is responsible for this. Try to revert and see
> > if things work again.
> > 
> 
> I tried backing out r254025, but there had been enough time that other
> commits had touched the same files.  Ended up backing out r254165,
> r254171, r254172, and r254182 as well (which seemed to go OK), but the
> result didn't build.
> 
> So I just checked out a new src working copy @r254024, built the world
> and kernel cleanly, verified that it booted OK, then updated the src
> working copy to r254025, built, booted, and ... BANG!
> 
> Booting...
> GDB: no debug ports present
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> Copyright (c) 1992-2013 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 10.0-CURRENT #3  r254025M/254025:141: Mon Aug 12 14:23:48 PDT 2013
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386
> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
> WARNING: WITNESS option enabled, expect reduced performance.
> panic: Assertion strat == M_BESTFIT || strat == M_FIRSTFIT failed at 
> /usr/src/sys/kern/subr_vmem.c:1050
> cpuid = 0
> KDB: enter: panic
> [ thread pid 0 tid 0 ]
> Stopped at  kdb_enter+0x3d: movl$0,kdb_why
> db> 
> 
> So I think it's fair to say that r254025 introduced the problem.
> 
> I'll go ahead and use kernel configs without DEBUG_MEMGUARD on head
> until this is resolved (or I have an opportunity to test patches
> for someone).
> 
> The r254025 environment is on a "spare" slice of the boot drive of
> the machine, so I can leave it for now.  My more usual (active)
> "head" slice is running:
> 
> FreeBSD 10.0-CURRENT #1243  r254245M/254246:142: Mon Aug 12 05:39:42 PDT 
> 2013 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  
> i386
> 
> I'll be happy to test either or both.

The r254025 indeed introduced the problem, and Davide pointed out you a
workaround for the assertion triggering.

Proper fix for the memguard requires a policy of M_NEXTFIT or like, to
avoid a reuse of the previous allocated range as long as possible.

But, you have some further issue even after the assertion was silenced,
isn't it ?


pgpdXzRyg7ydB.pgp
Description: PGP signature

Re: i386 panic

2013-08-12 Thread Adrian Chadd 
... bug peter. And alfred. Alfred broke this stuff. :)



-adrian

On 12 August 2013 21:33, Sean Bruno  wrote:
> On Mon, 2013-08-12 at 21:36 -0600, Scott Long wrote:
>> On Aug 12, 2013, at 1:43 PM, Sean Bruno  wrote:
>>
>> > http://people.freebsd.org/~sbruno/10_i386_vmfault.txt
>> >
>> > I can never tell if stuff like this is because I'm not nerfing the
>> > system RAM correctly or if this is i386 bit-rot.
>> >
>> > I set hw.physmem="2g" in loader.conf to try and get the system to boot,
>> > but I don't think I did it right?
>> >
>>
>> That shouldn't happen.  Maybe you've run out of kmem?  It's limited to only
>> like 400MB on i386.  Or maybe you've blown out a data structure with all
>> of those CPUs.
>>
>> Scott
>>
>>
>
> Since we can still do this on stable/7 (gross), I kind of think this is
> a low priority regression.  Not even sure where to look, nor do I really
> want to.  :-)
>
> If someone has a clueby4 to thwack me around with, I'd appreciate it.
>
> Sean
>
> p.s. We won't be caring about this for much longer I fear over at
> $DAYJOB, so if someone wants to address this I can test it for a few
> more months.  After that, we won't care about it too much.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: i386 panic

2013-08-12 Thread Sean Bruno 
On Mon, 2013-08-12 at 21:36 -0600, Scott Long wrote:
> On Aug 12, 2013, at 1:43 PM, Sean Bruno  wrote:
> 
> > http://people.freebsd.org/~sbruno/10_i386_vmfault.txt
> > 
> > I can never tell if stuff like this is because I'm not nerfing the
> > system RAM correctly or if this is i386 bit-rot.  
> > 
> > I set hw.physmem="2g" in loader.conf to try and get the system to boot,
> > but I don't think I did it right?
> > 
> 
> That shouldn't happen.  Maybe you've run out of kmem?  It's limited to only
> like 400MB on i386.  Or maybe you've blown out a data structure with all
> of those CPUs.
> 
> Scott
> 
> 

Since we can still do this on stable/7 (gross), I kind of think this is
a low priority regression.  Not even sure where to look, nor do I really
want to.  :-)

If someone has a clueby4 to thwack me around with, I'd appreciate it.

Sean

p.s. We won't be caring about this for much longer I fear over at
$DAYJOB, so if someone wants to address this I can test it for a few
more months.  After that, we won't care about it too much.


signature.asc
Description: This is a digitally signed message part

Re: quick hack to support "option VIMAGE" on USB Ethernet

2013-08-12 Thread YAMAMOTO Shigeru 

Hi all,

From: Craig Rodrigues 
Subject: Re: quick hack to support "option VIMAGE" on USB Ethernet
Date: Mon, 12 Aug 2013 17:52:39 -0700
> I do not have a USB Ethernet device, and do not fully understand VIMAGE yet.
> Is your patch still necessary in CURRENT, after this patch was applied to
> subr_bus.c?
> 
> http://lists.freebsd.org/pipermail/svn-src-all/2013-July/071878.html

I make a patch for r254236@HEAD which is newer than r253346.

My try is,
1) I try to enable "option VIMAGE" at r254236@HEAD.
It causes panic at accessing V_if_index in ifindex_alloc_locked().

2) I try to protect if_alloc(IFT_ETHER) at ue_attach_post_task() using
 CURVNET_SET_QUIET(curvnet) and CURVNET_RESTORE().
It causes abort at CURVNET_SET_QUIET() becasue curvnet is NULL.

3) I create my patch.
It is saving curvnet at uether_ifattach() and using saved curvnet at calling
CURVNET_SET_QUIET().
It seems me work.

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

Re: i386 panic

2013-08-12 Thread Scott Long 

On Aug 12, 2013, at 1:43 PM, Sean Bruno  wrote:

> http://people.freebsd.org/~sbruno/10_i386_vmfault.txt
> 
> I can never tell if stuff like this is because I'm not nerfing the
> system RAM correctly or if this is i386 bit-rot.  
> 
> I set hw.physmem="2g" in loader.conf to try and get the system to boot,
> but I don't think I did it right?
> 

That shouldn't happen.  Maybe you've run out of kmem?  It's limited to only
like 400MB on i386.  Or maybe you've blown out a data structure with all
of those CPUs.

Scott


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

Re: Notebook, Geforce Gtx 660M and ibtel HD

2013-08-12 Thread Paulo Henrique - BSDs Brasil 
On 11/08/2013 16:37, Nenhum_de_Nos wrote:
> Hail, 
> 
> I am back to desktoo and FreeBSD, but I cant pass the simple test to make X 
> alive. Xorg -configure detects two vga and two displays, but neither seems to 
> work. On 9.2rc I got to show X, but deadlock soon after. Now I installed 
> head, and cant even get X to work. The nvidia driver refuses to install, tons 
> of errors (not at home now to copy the messages). I have optimus nvidia 
> hardware. 
> 
> Is there any guide to this? Any vga working will do, if capable to play 
> videos and do 2d stuff. 
> 
> Thanks in advance, 
> 
> Matheus
> 
> " We will call you Cygnus,
> The God of balance you shall be" 
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

Thanks for the tip, now I think I found what I was not running my vga !!


http://www.nvidia.com/object/freebsd-x64-319.12-driver.html

-- 
Paulo Henrique.

/*
 * Não tenho apego material,
 * Só que tambem não vivemos em um mundo socialista.
 */
BSDs Brasil.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: quick hack to support "option VIMAGE" on USB Ethernet

2013-08-12 Thread Craig Rodrigues 
Hi,

I do not have a USB Ethernet device, and do not fully understand VIMAGE yet.
Is your patch still necessary in CURRENT, after this patch was applied to
subr_bus.c?

http://lists.freebsd.org/pipermail/svn-src-all/2013-July/071878.html

--
Craig



On Sun, Aug 11, 2013 at 8:48 PM, YAMAMOTO Shigeru  wrote:

>
> Hi all,
>
> I hope to use "option VIMAGE" on RaspberryPi.
>
> So, I try to make a patch.
>
> http://freebsd-current.os-hackers.jp/pub/FreeBSD/snapshots/20130812/raspberry-pi/patch-vimage-r254236.diff
> #There is a SD image for RaspberryPi at same place.
>
> But, I only test it for if_smsc driver on RaspberryPi.
> I don't test other architectures/devices.
>
> Please test my patch and suggest the way to support "option VIMAGE" on USB
> devices, if you are interested in.
>
> Thanks,
> ---
> YAMAMOTO Shigeru 
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: i386 panic

2013-08-12 Thread Super Bisquit 
Download the source and build the PAE kernel. Do the build world.



On Mon, Aug 12, 2013 at 7:02 PM, Sean Bruno  wrote:

> On Mon, 2013-08-12 at 12:43 -0700, Sean Bruno wrote:
> > http://people.freebsd.org/~sbruno/10_i386_vmfault.txt
> >
> > I can never tell if stuff like this is because I'm not nerfing the
> > system RAM correctly or if this is i386 bit-rot.
> >
> > I set hw.physmem="2g" in loader.conf to try and get the system to boot,
> > but I don't think I did it right?
> >
> > Sean
>
> The 9.2RC images seem to do the same thing when nerfed to 2G of ram.
> So, this doesn't appear to be a new regression.
>
> stable/7 seems to be happy enough to boot up PAE i386 on it, so I think
> the previous suggestion of using PAE is the correct one.
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: i386 panic

2013-08-12 Thread Sean Bruno 
On Mon, 2013-08-12 at 12:43 -0700, Sean Bruno wrote:
> http://people.freebsd.org/~sbruno/10_i386_vmfault.txt
> 
> I can never tell if stuff like this is because I'm not nerfing the
> system RAM correctly or if this is i386 bit-rot.  
> 
> I set hw.physmem="2g" in loader.conf to try and get the system to boot,
> but I don't think I did it right?
> 
> Sean

The 9.2RC images seem to do the same thing when nerfed to 2G of ram.
So, this doesn't appear to be a new regression.  

stable/7 seems to be happy enough to boot up PAE i386 on it, so I think
the previous suggestion of using PAE is the correct one.


signature.asc
Description: This is a digitally signed message part

Re: i386 panic

2013-08-12 Thread Sean Bruno 
Yah, I don't want to access the RAM, I just want the ridiculous box to
boot.  I'm content, for this test settting, to nerf myself to 4G rams.

Sean

On Mon, 2013-08-12 at 17:59 -0400, Super Bisquit wrote:
> You need to enable PAE in the kernel to access that memory.
> 
> I could be wrong.
> 
> 
> 
> On Mon, Aug 12, 2013 at 3:43 PM, Sean Bruno 
> wrote:
> http://people.freebsd.org/~sbruno/10_i386_vmfault.txt
> 
> I can never tell if stuff like this is because I'm not nerfing
> the
> system RAM correctly or if this is i386 bit-rot.
> 
> I set hw.physmem="2g" in loader.conf to try and get the system
> to boot,
> but I don't think I did it right?
> 
> Sean
> 
> 



signature.asc
Description: This is a digitally signed message part

Re: i386 panic

2013-08-12 Thread Super Bisquit 
You need to enable PAE in the kernel to access that memory.
I could be wrong.


On Mon, Aug 12, 2013 at 3:43 PM, Sean Bruno  wrote:

> http://people.freebsd.org/~sbruno/10_i386_vmfault.txt
>
> I can never tell if stuff like this is because I'm not nerfing the
> system RAM correctly or if this is i386 bit-rot.
>
> I set hw.physmem="2g" in loader.conf to try and get the system to boot,
> but I don't think I did it right?
>
> Sean
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Early drop to debugger with DEBUG_MEMGUARD

2013-08-12 Thread David Wolfskill 
On Mon, Aug 12, 2013 at 09:10:55AM -0700, Davide Italiano wrote:
> ...
> OK, I'm not sure I can make an immediate guess on where's the problem
> now (without access to my main workstation), so I think you need to
> wait tomorrow unless someone beats me to the punch. The best I can say
> is that maybe r254025 is responsible for this. Try to revert and see
> if things work again.
> 

I tried backing out r254025, but there had been enough time that other
commits had touched the same files.  Ended up backing out r254165,
r254171, r254172, and r254182 as well (which seemed to go OK), but the
result didn't build.

So I just checked out a new src working copy @r254024, built the world
and kernel cleanly, verified that it booted OK, then updated the src
working copy to r254025, built, booted, and ... BANG!

Booting...
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #3  r254025M/254025:141: Mon Aug 12 14:23:48 PDT 2013
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
WARNING: WITNESS option enabled, expect reduced performance.
panic: Assertion strat == M_BESTFIT || strat == M_FIRSTFIT failed at 
/usr/src/sys/kern/subr_vmem.c:1050
cpuid = 0
KDB: enter: panic
[ thread pid 0 tid 0 ]
Stopped at  kdb_enter+0x3d: movl$0,kdb_why
db> 

So I think it's fair to say that r254025 introduced the problem.

I'll go ahead and use kernel configs without DEBUG_MEMGUARD on head
until this is resolved (or I have an opportunity to test patches
for someone).

The r254025 environment is on a "spare" slice of the boot drive of
the machine, so I can leave it for now.  My more usual (active)
"head" slice is running:

FreeBSD 10.0-CURRENT #1243  r254245M/254246:142: Mon Aug 12 05:39:42 PDT 
2013 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  i386

I'll be happy to test either or both.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil men with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpHLwUoIYF7k.pgp
Description: PGP signature

make[6]: stopped in /usr/src/lib/bind/dns

2013-08-12 Thread AN 
FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #78 r253966: Mon Aug  5 
14:42:05 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64


# svn info
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 254252
Node Kind: directory
Schedule: normal
Last Changed Author: ed
Last Changed Rev: 254252
Last Changed Date: 2013-08-12 13:17:45 -0500 (Mon, 12 Aug 2013)


c   -O2 -pipe  -DVERSION='"9.8.5-P2"' -DHAVE_CONFIG_H -D_REENTRANT 
-D_THREAD_SAFE -DLIBINTERFACE=122 -DLIBREVISION=1 -DLIBAGE=0 -DWANT_IPV6 
-DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' 
-DNS_SYSCONFDIR='"/etc/namedb"' 
-DNAMED_CONFFILE='"/etc/namedb/named.conf"' 
-DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' 
-DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/usr/src/lib/bind/dns/.. 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/bind9/include 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include/dst 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include 
-I/usr/src/lib/bind/dns/../dns 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/isccc/include 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/isccfg/include 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/isc/unix/include 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/isc/pthreads/include 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/isc/include 
-I/usr/src/lib/bind/dns/../isc 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/lwres/unix/include 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/lwres/include 
-I/usr/src/lib/bind/dns/../lwres 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include/dst 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/include 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns 
-I/usr/src/lib/bind/dns 
-I/usr/src/lib/bind/dns/../../../contrib/bind9/lib/isc/x86_32/include 
-std=gnu99 -Qunused-arguments -fstack-protector  -c 
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c -o zone.o
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:2772:23: 
warning: comparison of constant 245 with
  expression of type 'dns_hash_t' is always false 
[-Wtautological-constant-out-of-range-compare]

nsec3param.hash == DNS_NSEC3_UNKNOWNALG && !dynamic)
~~~ ^  
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:11: 
warning: null character ignored

  [-Wnull-character]
isc_time_
 ^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:12: 
warning: null character ignored

  [-Wnull-character]
isc_time_
 ^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:13: 
warning: null character ignored

  [-Wnull-character]
isc_time_
 ^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:14: 
warning: null character ignored

  [-Wnull-character]
isc_time_
 ^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:15: 
warning: null character ignored

  [-Wnull-character]
isc_time_
 ^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:16: 
warning: null character ignored

  [-Wnull-character]
isc_time_
 ^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:17: 
warning: null character ignored

  [-Wnull-character]
isc_time_
 ^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:18: 
warning: null character ignored

  [-Wnull-character]
isc_time_
 ^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:19: 
warning: null character ignored

  [-Wnull-character]

isc_time_

^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:20: 
warning: null character ignored

  [-Wnull-character]

isc_time_

^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:21: 
warning: null character ignored

  [-Wnull-character]

isc_time_

^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:22: 
warning: null character ignored

  [-Wnull-character]

isc_time_

^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:23: 
warning: null character ignored

  [-Wnull-character]

isc_time_

^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:24: 
warning: null character ignored

  [-Wnull-character]
  ...
 ^
/usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:25: 
warning: null character ignored

  [-Wnull-character]
  ...
 ^
/usr/src/lib/bind

i386 panic

2013-08-12 Thread Sean Bruno 
http://people.freebsd.org/~sbruno/10_i386_vmfault.txt

I can never tell if stuff like this is because I'm not nerfing the
system RAM correctly or if this is i386 bit-rot.  

I set hw.physmem="2g" in loader.conf to try and get the system to boot,
but I don't think I did it right?

Sean


signature.asc
Description: This is a digitally signed message part

Re: Early drop to debugger with DEBUG_MEMGUARD

2013-08-12 Thread Davide Italiano 
On Mon, Aug 12, 2013 at 9:01 AM, David Wolfskill  wrote:
> On Mon, Aug 12, 2013 at 08:30:15AM -0700, Davide Italiano wrote:
>> ...
>> > Booting...
>> > GDB: no debug ports present
>> > KDB: debugger backends: ddb
>> > KDB: current backend: ddb
>> > Copyright (c) 1992-2013 The FreeBSD Project.
>> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>> > The Regents of the University of California. All rights reserved.
>> > FreeBSD is a registered trademark of The FreeBSD Foundation.
>> > FreeBSD 10.0-CURRENT #0  r254245M/254246:142: Mon Aug 12 07:20:47 PDT 
>> > 2013
>> > r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386
>> > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>> > WARNING: WITNESS option enabled, expect reduced performance.
>> > panic: Assertion strat == M_BESTFIT || strat == M_FIRSTFIT failed at 
>> > /usr/src/sys/kern/subr_vmem.c:1050
>> > cpuid = 0
>> > KDB: stack backtrace:
>> > db_trace_self_wrapper(c116fcdc,73752f20,72732f72,79732f63,656b2f73,...) at 
>> > db_trace_self_wrapper+0x2d/frame 0xc1820ba0
>> > kdb_backtrace(c11c4b23,0,c0f8a835,c1820c74,c0f8a835,...) at 
>> > kdb_backtrace+0x30/frame 0xc1820c08
>> > vpanic(c12eea08,100,c0f8a835,c1820c74,c1820c74,...) at vpanic+0x11f/frame 
>> > 0xc1820c44
>> > kassert_panic(c0f8a835,c1172e98,c1172e39,41a,8,...) at 
>> > kassert_panic+0xea/frame 0xc1820c68
>> > vmem_alloc(c130d680,6681000,2,c1820cc0,3b5,...) at vmem_alloc+0x53/frame 
>> > 0xc1820ca0
>> > memguard_init(c130d680,c0a9fa50,c680,20281000,1000,1,0) at 
>> > memguard_init+0x29/frame 0xc1820cc4
>> > kmeminit(c14b9fd4,c10efc89,0,0,c1820d30,...) at kmeminit+0x171/frame 
>> > 0xc1820cf0
>> > mallocinit(0,0,2,0,c11d3728,...) at mallocinit+0x32/frame 0xc1820d30
>> > mi_startup() at mi_startup+0xf7/frame 0xc1820d58
>> > begin() at begin+0x2c
>> > KDB: enter: panic
>> > [ thread pid 0 tid 0 ]
>> > Stopped at  kdb_enter+0x3d: movl$0,kdb_why
>> > db>
>> >
>> > As you can see, this is well before any device probes or much of
>> > anything else.  Thus, I suspect that it's fairly possible that the
>> > assertion may well be OK after a certain point in the boot sequence,
>> > but decidedly *not* OK in this specific instance.  Or perhaps the
>> > assertion just doesn't play well with DEBUG_MEMGUARD.
>> ...
>
>> vmem_alloc() KPI needs the consumer to specify exactly a strategy for
>> allocation, which is one of two between: M_FIRSTFIT/M_BESTFIT (fast
>> allocation vs low fragmentation), and that's the assertion that's not
>> respected within the code.
>>
>> 1050  MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT);
>>
>> It looks like memguard_init() doesn't specify none of these two strategies.
>>
>> 209   vmem_alloc(parent, memguard_mapsize, M_WAITOK, &base);
>>
>> My guess is that you need to OR one between M_BESTFIT/M_FIRSTFIT with
>> M_WAITOK to have your kernel booting. What's better between the two
>> probably will need some measurements but this should at least make
>> your kernel booting.
>
> Thank you for the insight & suggestion.
>
> My first attempt was to make the following change:
>
> Index: sys/vm/memguard.c
> ===
> --- sys/vm/memguard.c   (revision 254246)
> +++ sys/vm/memguard.c   (working copy)
> @@ -206,9 +206,9 @@
>  {
> vm_offset_t base;
>
> -   vmem_alloc(parent, memguard_mapsize, M_WAITOK, &base);
> +   vmem_alloc(parent, memguard_mapsize, M_WAITOK | M_FIRSTFIT, &base);
> memguard_map = vmem_create("memguard arena", base, memguard_mapsize,
> -   PAGE_SIZE, 0, M_WAITOK);
> +   PAGE_SIZE, 0, M_WAITOK | M_FIRSTFIT);
> memguard_cursor = base;
> memguard_base = base;
>
> This built OK; but attempting to boot yielded:
>
> Booting...
> GDB: no debug ports present
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> Copyright (c) 1992-2013 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 10.0-CURRENT #1  r254245M/254246:142: Mon Aug 12 08:49:12 PDT 2013
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386
> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
> WARNING: WITNESS option enabled, expect reduced performance.
> panic: mti_zone 195 out of range 8
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper(c116fcdc,0,,c1167d73,fffe,...) at 
> db_trace_self_wrapper+0x2d/frame 0xc1820b58
> kdb_backtrace(c11c4b23,0,c1167d58,c1820c30,c1820c00,...) at 
> kdb_backtrace+0x30/frame 0xc1820bc0
> vpanic(c12eea08,100,c1167d58,c1820c30,c1820c30,...) at vpanic+0x11f/frame 
> 0xc1820c00
> kassert_panic(c1167d58,c3,8,c130d7e4,c130d7a8,...) at 
> kassert_panic+0xea/frame 0xc1820c24
> malloc(380,c1279778,2,0,,...

Re: Early drop to debugger with DEBUG_MEMGUARD

2013-08-12 Thread David Wolfskill 
On Mon, Aug 12, 2013 at 08:30:15AM -0700, Davide Italiano wrote:
> ...
> > Booting...
> > GDB: no debug ports present
> > KDB: debugger backends: ddb
> > KDB: current backend: ddb
> > Copyright (c) 1992-2013 The FreeBSD Project.
> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> > The Regents of the University of California. All rights reserved.
> > FreeBSD is a registered trademark of The FreeBSD Foundation.
> > FreeBSD 10.0-CURRENT #0  r254245M/254246:142: Mon Aug 12 07:20:47 PDT 
> > 2013
> > r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386
> > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
> > WARNING: WITNESS option enabled, expect reduced performance.
> > panic: Assertion strat == M_BESTFIT || strat == M_FIRSTFIT failed at 
> > /usr/src/sys/kern/subr_vmem.c:1050
> > cpuid = 0
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c116fcdc,73752f20,72732f72,79732f63,656b2f73,...) at 
> > db_trace_self_wrapper+0x2d/frame 0xc1820ba0
> > kdb_backtrace(c11c4b23,0,c0f8a835,c1820c74,c0f8a835,...) at 
> > kdb_backtrace+0x30/frame 0xc1820c08
> > vpanic(c12eea08,100,c0f8a835,c1820c74,c1820c74,...) at vpanic+0x11f/frame 
> > 0xc1820c44
> > kassert_panic(c0f8a835,c1172e98,c1172e39,41a,8,...) at 
> > kassert_panic+0xea/frame 0xc1820c68
> > vmem_alloc(c130d680,6681000,2,c1820cc0,3b5,...) at vmem_alloc+0x53/frame 
> > 0xc1820ca0
> > memguard_init(c130d680,c0a9fa50,c680,20281000,1000,1,0) at 
> > memguard_init+0x29/frame 0xc1820cc4
> > kmeminit(c14b9fd4,c10efc89,0,0,c1820d30,...) at kmeminit+0x171/frame 
> > 0xc1820cf0
> > mallocinit(0,0,2,0,c11d3728,...) at mallocinit+0x32/frame 0xc1820d30
> > mi_startup() at mi_startup+0xf7/frame 0xc1820d58
> > begin() at begin+0x2c
> > KDB: enter: panic
> > [ thread pid 0 tid 0 ]
> > Stopped at  kdb_enter+0x3d: movl$0,kdb_why
> > db>
> >
> > As you can see, this is well before any device probes or much of
> > anything else.  Thus, I suspect that it's fairly possible that the
> > assertion may well be OK after a certain point in the boot sequence,
> > but decidedly *not* OK in this specific instance.  Or perhaps the
> > assertion just doesn't play well with DEBUG_MEMGUARD.
> ...

> vmem_alloc() KPI needs the consumer to specify exactly a strategy for
> allocation, which is one of two between: M_FIRSTFIT/M_BESTFIT (fast
> allocation vs low fragmentation), and that's the assertion that's not
> respected within the code.
> 
> 1050  MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT);
> 
> It looks like memguard_init() doesn't specify none of these two strategies.
> 
> 209   vmem_alloc(parent, memguard_mapsize, M_WAITOK, &base);
> 
> My guess is that you need to OR one between M_BESTFIT/M_FIRSTFIT with
> M_WAITOK to have your kernel booting. What's better between the two
> probably will need some measurements but this should at least make
> your kernel booting.

Thank you for the insight & suggestion.

My first attempt was to make the following change:

Index: sys/vm/memguard.c
===
--- sys/vm/memguard.c   (revision 254246)
+++ sys/vm/memguard.c   (working copy)
@@ -206,9 +206,9 @@
 {
vm_offset_t base;
 
-   vmem_alloc(parent, memguard_mapsize, M_WAITOK, &base);
+   vmem_alloc(parent, memguard_mapsize, M_WAITOK | M_FIRSTFIT, &base);
memguard_map = vmem_create("memguard arena", base, memguard_mapsize,
-   PAGE_SIZE, 0, M_WAITOK);
+   PAGE_SIZE, 0, M_WAITOK | M_FIRSTFIT);
memguard_cursor = base;
memguard_base = base;
 
This built OK; but attempting to boot yielded:

Booting...
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #1  r254245M/254246:142: Mon Aug 12 08:49:12 PDT 2013
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
WARNING: WITNESS option enabled, expect reduced performance.
panic: mti_zone 195 out of range 8
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c116fcdc,0,,c1167d73,fffe,...) at 
db_trace_self_wrapper+0x2d/frame 0xc1820b58
kdb_backtrace(c11c4b23,0,c1167d58,c1820c30,c1820c00,...) at 
kdb_backtrace+0x30/frame 0xc1820bc0
vpanic(c12eea08,100,c1167d58,c1820c30,c1820c30,...) at vpanic+0x11f/frame 
0xc1820c00
kassert_panic(c1167d58,c3,8,c130d7e4,c130d7a8,...) at kassert_panic+0xea/frame 
0xc1820c24
malloc(380,c1279778,2,0,,...) at malloc+0x308/frame 0xc1820c70
vmem_create(c11a7530,c680,6681000,1000,0,...) at vmem_create+0x29/frame 
0xc1820ca0
memguard_init(c130d680,c0a9fa50,c680,20281000,1000,1,0) at 
memguard_ini

Re: Early drop to debugger with DEBUG_MEMGUARD

2013-08-12 Thread Davide Italiano 
On Mon, Aug 12, 2013 at 8:13 AM, David Wolfskill  wrote:
> I first noticed this on my laptop on 08 Aug, after having built & booted
>
> FreeBSD 10.0-CURRENT #975  r253985M/253985:141: Tue Aug  6 05:28:39 PDT 
> 2013 root@localhost:/common/S4/obj/usr/src/sys/CANARY  i386
>
> OK.  I'm away from home, and Internet access is a bit flaky, so
> initially, I suspected that something may have gone wrong with my
> source update; I later determined that disabling "options DEBUG_MEMGUARD"
> would avoid the panic.
>
> That said, I had been running a kernel with DEBUG_MEMGUARD for quite
> a while without issues; I suspect that this drop to debugger either
> reflects a real problem that disabling DEBUG_MEMGUARD merely hides
> or htat the assert in src/sys/kern/subr_vmem.c:1050 isn't actually
> correct in all cases.
>
> So I finally(!) had a chance to try to reproduce the error on a
> machine with a serial console; here's a cut/paste from that:
>
> ...
>  |  7. Boot [V]erbose: NO  |`:`  `:`
>  | |  .-- `--.
>  | | .---..
>  +-+
>
>
> Booting...
> GDB: no debug ports present
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> Copyright (c) 1992-2013 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 10.0-CURRENT #0  r254245M/254246:142: Mon Aug 12 07:20:47 PDT 2013
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386
> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
> WARNING: WITNESS option enabled, expect reduced performance.
> panic: Assertion strat == M_BESTFIT || strat == M_FIRSTFIT failed at 
> /usr/src/sys/kern/subr_vmem.c:1050
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper(c116fcdc,73752f20,72732f72,79732f63,656b2f73,...) at 
> db_trace_self_wrapper+0x2d/frame 0xc1820ba0
> kdb_backtrace(c11c4b23,0,c0f8a835,c1820c74,c0f8a835,...) at 
> kdb_backtrace+0x30/frame 0xc1820c08
> vpanic(c12eea08,100,c0f8a835,c1820c74,c1820c74,...) at vpanic+0x11f/frame 
> 0xc1820c44
> kassert_panic(c0f8a835,c1172e98,c1172e39,41a,8,...) at 
> kassert_panic+0xea/frame 0xc1820c68
> vmem_alloc(c130d680,6681000,2,c1820cc0,3b5,...) at vmem_alloc+0x53/frame 
> 0xc1820ca0
> memguard_init(c130d680,c0a9fa50,c680,20281000,1000,1,0) at 
> memguard_init+0x29/frame 0xc1820cc4
> kmeminit(c14b9fd4,c10efc89,0,0,c1820d30,...) at kmeminit+0x171/frame 
> 0xc1820cf0
> mallocinit(0,0,2,0,c11d3728,...) at mallocinit+0x32/frame 0xc1820d30
> mi_startup() at mi_startup+0xf7/frame 0xc1820d58
> begin() at begin+0x2c
> KDB: enter: panic
> [ thread pid 0 tid 0 ]
> Stopped at  kdb_enter+0x3d: movl$0,kdb_why
> db>
>
> As you can see, this is well before any device probes or much of
> anything else.  Thus, I suspect that it's fairly possible that the
> assertion may well be OK after a certain point in the boot sequence,
> but decidedly *not* OK in this specific instance.  Or perhaps the
> assertion just doesn't play well with DEBUG_MEMGUARD.
>
> I'm not about to pretend that I have anywhere near enough familiarity
> with what's going on to even suggest a fix, but it seems to me that
> Something Is Wrong Here.
>
> The kernel config (in this case) is:
>
> include GENERIC
>
> ident   MEMGUARD
>
> options DEBUG_MEMGUARD
>
>
> The system was running a copy of:
>
> FreeBSD 10.0-CURRENT #1243  r254245M/254246:142: Mon Aug 12 05:39:42 PDT 
> 2013 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  
> i386
>
> but with a newly-built MEMGUARD kernel (as above), built from the same
> sources.
>
> I have some time to poke at it for the next few hours; subject to
> my Internet access & available time, I'm happy to do that, try
> patches, or whatever, but I could use a bit of guidance.
>
> Since it's been completely reproducible for me, I suspect that
> anyone with sufficiently recenty sources running head can reproduce
> it merely by enabling "options DEBUG_MEMGUARD", rebuilding the
> kernel, and booting it.
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Taliban: Evil men with guns afraid of truth from a 14-year old girl.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.

vmem_alloc() KPI needs the consumer to specify exactly a strategy for
allocation, which is one of two between: M_FIRSTFIT/M_BESTFIT (fast
allocation vs low fragmentation), and that's the assertion that's not
respected within the code.

1050MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT);

It looks like memguard_init() doesn't specify none of these two strategies.

209 vmem_alloc(parent, memguard_mapsize, M_WAITOK, &ba

Early drop to debugger with DEBUG_MEMGUARD

2013-08-12 Thread David Wolfskill 
I first noticed this on my laptop on 08 Aug, after having built & booted

FreeBSD 10.0-CURRENT #975  r253985M/253985:141: Tue Aug  6 05:28:39 PDT 
2013 root@localhost:/common/S4/obj/usr/src/sys/CANARY  i386

OK.  I'm away from home, and Internet access is a bit flaky, so
initially, I suspected that something may have gone wrong with my
source update; I later determined that disabling "options DEBUG_MEMGUARD"
would avoid the panic.

That said, I had been running a kernel with DEBUG_MEMGUARD for quite
a while without issues; I suspect that this drop to debugger either
reflects a real problem that disabling DEBUG_MEMGUARD merely hides
or htat the assert in src/sys/kern/subr_vmem.c:1050 isn't actually
correct in all cases.

So I finally(!) had a chance to try to reproduce the error on a
machine with a serial console; here's a cut/paste from that:

...
 |  7. Boot [V]erbose: NO  |`:`  `:`
 | |  .-- `--.
 | | .---..
 +-+
  

Booting...
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #0  r254245M/254246:142: Mon Aug 12 07:20:47 PDT 2013
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
WARNING: WITNESS option enabled, expect reduced performance.
panic: Assertion strat == M_BESTFIT || strat == M_FIRSTFIT failed at 
/usr/src/sys/kern/subr_vmem.c:1050
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c116fcdc,73752f20,72732f72,79732f63,656b2f73,...) at 
db_trace_self_wrapper+0x2d/frame 0xc1820ba0
kdb_backtrace(c11c4b23,0,c0f8a835,c1820c74,c0f8a835,...) at 
kdb_backtrace+0x30/frame 0xc1820c08
vpanic(c12eea08,100,c0f8a835,c1820c74,c1820c74,...) at vpanic+0x11f/frame 
0xc1820c44
kassert_panic(c0f8a835,c1172e98,c1172e39,41a,8,...) at kassert_panic+0xea/frame 
0xc1820c68
vmem_alloc(c130d680,6681000,2,c1820cc0,3b5,...) at vmem_alloc+0x53/frame 
0xc1820ca0
memguard_init(c130d680,c0a9fa50,c680,20281000,1000,1,0) at 
memguard_init+0x29/frame 0xc1820cc4
kmeminit(c14b9fd4,c10efc89,0,0,c1820d30,...) at kmeminit+0x171/frame 0xc1820cf0
mallocinit(0,0,2,0,c11d3728,...) at mallocinit+0x32/frame 0xc1820d30
mi_startup() at mi_startup+0xf7/frame 0xc1820d58
begin() at begin+0x2c
KDB: enter: panic
[ thread pid 0 tid 0 ]
Stopped at  kdb_enter+0x3d: movl$0,kdb_why
db> 

As you can see, this is well before any device probes or much of
anything else.  Thus, I suspect that it's fairly possible that the
assertion may well be OK after a certain point in the boot sequence,
but decidedly *not* OK in this specific instance.  Or perhaps the
assertion just doesn't play well with DEBUG_MEMGUARD.

I'm not about to pretend that I have anywhere near enough familiarity
with what's going on to even suggest a fix, but it seems to me that
Something Is Wrong Here.

The kernel config (in this case) is:

include GENERIC

ident   MEMGUARD

options DEBUG_MEMGUARD


The system was running a copy of:

FreeBSD 10.0-CURRENT #1243  r254245M/254246:142: Mon Aug 12 05:39:42 PDT 
2013 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  i386

but with a newly-built MEMGUARD kernel (as above), built from the same
sources.

I have some time to poke at it for the next few hours; subject to
my Internet access & available time, I'm happy to do that, try
patches, or whatever, but I could use a bit of guidance.

Since it's been completely reproducible for me, I suspect that
anyone with sufficiently recenty sources running head can reproduce
it merely by enabling "options DEBUG_MEMGUARD", rebuilding the
kernel, and booting it.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil men with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpG5X8v7wWXi.pgp
Description: PGP signature

Re: control of order of inet devices

2013-08-12 Thread Brooks Davis 
On Mon, Aug 05, 2013 at 11:16:03AM +0200, Willy Offermans wrote:
> Hello Brooks,
> 
> On Wed, Apr 17, 2013 at 03:01:27PM -0500, Brooks Davis wrote:
> > On Wed, Apr 17, 2013 at 04:27:44AM -0500, Joshua Isom wrote:
> > > On 4/17/2013 4:14 AM, Willy Offermans wrote:
> > > > This is what I read in some of the articles or handbook as well. Can I
> > > > reorder this linked list? Can I control the order by creating the kernel
> > > > and reordering the inclusion of the device drivers?
> > > >
> > > > I am aware that the request sounds silly, but I have a third party 
> > > > program
> > > > which checks its licence against the first inet device. Since I have 
> > > > added
> > > > a new inet controller, the sequence has changed. Of course I ask for a 
> > > > new
> > > > licence, but they want to charge me for that and I do not see any reason
> > > > for that.
> > > 
> > > Load old inet devices like normal, in loader.conf.  Then load the new 
> > > device driver before networking, after rc's started.  If it'd because of 
> > > probe order, then you might just have to control the probe order the 
> > > hard way.  If the program's calling ifconfig itself, you could write a 
> > > wrapper to resort the output.  And call a lawyer, getting a new ethernet 
> > > card shouldn't void a license.
> > 
> > It wouldn't be particularly hard to influence the sorting of the list if
> > you're willing to modify the if_attach_internal() function and always
> > insert devices with that name at the beginning.  It just doesn't seem
> > very general purpose so I'd have a hard time considering including it.
> > 
> > -- Brooks
> 
> I see und subscribe to your point. However it is not clear to me how the
> order is established. Maybe if I know that, I can influence the order. Can
> you comment on that?

The order is simply the order the devices probe in.  That's basicaly a
black box with the order set by the bus hierarchy.

> Where can I find the code for the if_attach_internal() function? Digging
> into the code might also elucidate a lot of things, so I need to ask less
> :). Maybe I will change the code a bit to suite my wishes. If that is the
> case, I will inform the list and show the code. Maybe it is useful.

sys/net/if.c around line 586.

-- Brooks


pgpu8uP4NYq7W.pgp
Description: PGP signature

panic: UMA: Increase vm.boot_pages with 32 CPUs

2013-08-12 Thread Colin Percival 
Hi all,

A HEAD@254238 kernel fails to boot in EC2 with
> panic: UMA: Increase vm.boot_pages
on 32-CPU instances.  Instances with up to 16 CPUs boot fine.

I know there has been some mucking about with VM recently -- anyone want
to claim this, or should I start doing a binary search?

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"