panic: UMA: Increase vm.boot_pages with 32 CPUs
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
Re: control of order of inet devices
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
Early drop to debugger with DEBUG_MEMGUARD
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: Early drop to debugger with DEBUG_MEMGUARD
On Mon, Aug 12, 2013 at 8:13 AM, David Wolfskill da...@catwhisker.org 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, base); My guess is that you need to OR one between M_BESTFIT/M_FIRSTFIT with M_WAITOK to have
Re: Early drop to debugger with DEBUG_MEMGUARD
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_init+0x5e/frame 0xc1820cc4
kmeminit(c14b9fd4,c10efc89,0,0,c1820d30,...) at kmeminit+0x171/frame 0xc1820cf0
Re: Early drop to debugger with DEBUG_MEMGUARD
On Mon, Aug 12, 2013 at 9:01 AM, David Wolfskill da...@catwhisker.org 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,,...) 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
i386 panic
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
make[6]: stopped in /usr/src/lib/bind/dns
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_U+ ^ /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:13: warning: null character ignored [-Wnull-character] isc_time_U+U+ ^ /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:14: warning: null character ignored [-Wnull-character] isc_time_U+U+U+ ^ /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:15: warning: null character ignored [-Wnull-character] isc_time_U+U+U+U+ ^ /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:16: warning: null character ignored [-Wnull-character] isc_time_U+U+U+U+U+ ^ /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:17: warning: null character ignored [-Wnull-character] isc_time_U+U+U+U+U+U+ ^ /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:18: warning: null character ignored [-Wnull-character] isc_time_U+U+U+U+U+U+U+ ^ /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:19: warning: null character ignored [-Wnull-character] isc_time_U+U+U+U+U+U+U+U+ ^ /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:20: warning: null character ignored [-Wnull-character] isc_time_U+U+U+U+U+U+U+U+U+ ^ /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:21: warning: null character ignored [-Wnull-character] isc_time_U+U+U+U+U+U+U+U+U+U+ ^ /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/zone.c:14682:22: warning: null character ignored [-Wnull-character] isc_time_U+U+U+U+U+U+U+U+U+U+U+ ^
Re: Early drop to debugger with DEBUG_MEMGUARD
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
Re: i386 panic
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 sean_br...@yahoo.com 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: i386 panic
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 sean_br...@yahoo.com 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
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
Download the source and build the PAE kernel. Do the build world. On Mon, Aug 12, 2013 at 7:02 PM, Sean Bruno sean_br...@yahoo.com 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: quick hack to support option VIMAGE on USB Ethernet
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 shig...@iij.ad.jp 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 shig...@iij.ad.jp ___ 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: Notebook, Geforce Gtx 660M and ibtel HD
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: i386 panic
On Aug 12, 2013, at 1:43 PM, Sean Bruno sean_br...@yahoo.com 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: quick hack to support option VIMAGE on USB Ethernet
Hi all, From: Craig Rodrigues rodr...@freebsd.org 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 shig...@iij.ad.jp ___ 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
On Mon, 2013-08-12 at 21:36 -0600, Scott Long wrote: On Aug 12, 2013, at 1:43 PM, Sean Bruno sean_br...@yahoo.com 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: i386 panic
... bug peter. And alfred. Alfred broke this stuff. :) -adrian On 12 August 2013 21:33, Sean Bruno sean_br...@yahoo.com wrote: On Mon, 2013-08-12 at 21:36 -0600, Scott Long wrote: On Aug 12, 2013, at 1:43 PM, Sean Bruno sean_br...@yahoo.com 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: Early drop to debugger with DEBUG_MEMGUARD
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
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
