Re: zfs kernel panic, known incompatibilities with clang CPUTYPE/COPTFLAGS?
On 2013-06-14 23:07:02 (+0200), Alexander Leidinger alexan...@leidinger.net wrote: The bt in the minidump is useless, but I made a bt directly in the kernel debugger: ---snip--- Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff839e79d930 frame pointer = 0x28:0xff839e79d9e0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2183 (zfs) db bt Tracing pid 2356 uart_sab82532_class() at 0 devfs_ioctl_f() at devfs_ioctl_f+0xf0 kern_ioctl() at kern_ioctl+0x1d7 sys_ioctl() at sys_ioctl+0x142 ---snip--- For what it's worth, I'm running into exactly the same problem. (amd64, stable/9). I have no custom settings in /etc/make.conf or /etc/src.conf Regards, Kristof ___ 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: [panic] swi4 page fault (ip_slowtimo())
On Fri, Jun 21, 2013 at 08:17:12PM -0400, Glen Barber wrote:
G Hi,
G
G I have the following kgdb session from a page fault seemingly triggered
G in pf(4).
pfslowtimo() isn't related to pf(4). pf stands here for protocol family.
G (kgdb) list *0x80772688
G 0x80772688 is in ip_slowtimo (/usr/src/sys/netinet/ip_input.c:1242).
G 1237 for(fp = TAILQ_FIRST(V_ipq[i]); fp;) {
G 1238 struct ipq *fpp;
G 1239
G 1240 fpp = fp;
G 1241 fp = TAILQ_NEXT(fp, ipq_list);
G 1242 if(--fpp-ipq_ttl == 0) {
G 1243 IPSTAT_ADD(ips_fragtimeout,
G 1244 fpp-ipq_nfrags);
G 1245 ip_freef(V_ipq[i], fpp);
G 1246 }
G (kgdb) p *ipq
G $1 = {tqh_first = 0x0, tqh_last = 0x80e20e80}
Can you please print ipq, so that we can look at entire array.
--
Totus tuus, Glebius.
___
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: [panic] swi4 page fault (ip_slowtimo())
On Mon, Jun 24, 2013 at 02:21:56PM +0400, Gleb Smirnoff wrote:
On Fri, Jun 21, 2013 at 08:17:12PM -0400, Glen Barber wrote:
G Hi,
G
G I have the following kgdb session from a page fault seemingly triggered
G in pf(4).
pfslowtimo() isn't related to pf(4). pf stands here for protocol family.
Ah, thanks.
G (kgdb) list *0x80772688
G 0x80772688 is in ip_slowtimo
(/usr/src/sys/netinet/ip_input.c:1242).
G 1237 for(fp = TAILQ_FIRST(V_ipq[i]); fp;) {
G 1238 struct ipq *fpp;
G 1239
G 1240 fpp = fp;
G 1241 fp = TAILQ_NEXT(fp, ipq_list);
G 1242 if(--fpp-ipq_ttl == 0) {
G 1243
IPSTAT_ADD(ips_fragtimeout,
G 1244 fpp-ipq_nfrags);
G 1245 ip_freef(V_ipq[i],
fpp);
G 1246 }
G (kgdb) p *ipq
G $1 = {tqh_first = 0x0, tqh_last = 0x80e20e80}
Can you please print ipq, so that we can look at entire array.
Sure, output follows.
Glen
Script started on Mon Jun 24 06:28:36 2013
root@orion:/usr/obj/usr/src/sys/ORION # kgdb ./kernel.debug /var/crash/vmcore.8
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x11
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80772688
stack pointer = 0x28:0xff800026da20
frame pointer = 0x28:0xff800026da40
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi4: clock)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0x80676a46 at kdb_backtrace+0x66
#1 0x8063ae6b at panic+0x13b
#2 0x80918ba0 at trap_fatal+0x290
#3 0x80918f11 at trap_pfault+0x221
#4 0x809194c4 at trap+0x344
#5 0x80902c53 at calltrap+0x8
#6 0x806a29ce at pfslowtimo+0x2e
#7 0x80651476 at softclock_call_cc+0x106
#8 0x80651b09 at softclock+0xa9
#9 0x8060c06d at intr_event_execute_handlers+0xfd
#10 0x8060d81b at ithread_loop+0x9b
#11 0x80608c1f at fork_exit+0x11f
#12 0x8090317e at fork_trampoline+0xe
Uptime: 42d1h53m40s
(ada0:ahcich0:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:0): CAM status: CCB request is in progress
(ada0:ahcich0:0:0:0): Error 5, Retries exhausted
(ada0:ahcich0:0:0:0): Synchronize cache failed
(ada1:ahcich1:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00
(ada1:ahcich1:0:0:0): CAM status: CCB request is in progress
(ada1:ahcich1:0:0:0): Error 5, Retries exhausted
(ada1:ahcich1:0:0:0): Synchronize cache failed
(ada2:ahcich4:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00
(ada2:ahcich4:0:0:0): CAM status: CCB request is in progress
(ada2:ahcich4:0:0:0): Error 5, Retries exhausted
(ada2:ahcich4:0:0:0): Synchronize cache failed
(ada3:ahcich5:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00
(ada3:ahcich5:0:0:0): CAM status: CCB request is in progress
(ada3:ahcich5:0:0:0): Error 5, Retries exhausted
(ada3:ahcich5:0:0:0): Synchronize cache failed
Dumping 2263 out of 6048 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
#0 doadump (textdump=value optimized out) at pcpu.h:231
231 __asm(movq %%gs:%1,%0 : =r (td)
(kgdb) p ipq
$1 = {{tqh_first = 0x0, tqh_last = 0x80e20e80}, {tqh_first = 0x0,
tqh_last = 0x80e20e90}, {tqh_first = 0x0, tqh_last =
0x80e20ea0}, {
tqh_first = 0x0, tqh_last = 0x80e20eb0}, {tqh_first = 0x0,
tqh_last = 0x80e20ec0}, {tqh_first = 0x0, tqh_last =
0x80e20ed0}, {
tqh_first = 0x0, tqh_last = 0x80e20ee0}, {tqh_first = 0x0,
tqh_last = 0x80e20ef0}, {tqh_first = 0x0, tqh_last =
0x80e20f00}, {
tqh_first = 0x0, tqh_last = 0x80e20f10}, {tqh_first = 0x0,
tqh_last = 0x80e20f20}, {tqh_first = 0x0, tqh_last
dialog4ports crashing / dumping core
I've started seeing these on multiple machines in the last few days when building pretty much any port: +pid 23141 (dialog4ports), uid 0: exited on signal 6 (core dumped) +pid 23394 (dialog4ports), uid 0: exited on signal 6 (core dumped) +pid 23782 (dialog4ports), uid 0: exited on signal 6 (core dumped) +pid 24011 (dialog4ports), uid 0: exited on signal 6 (core dumped) +pid 24564 (dialog4ports), uid 0: exited on signal 6 (core dumped) +pid 24739 (dialog4ports), uid 0: exited on signal 6 (core dumped) I'll rebuild a box with debug symbols and get a decent trace but for now this is all I have on a couple systems running 10.0-CURRENT FreeBSD 10.0-CURRENT #11 r252104. This crash appears to happen after you exit the dialog4port dialog screen. root@darkstor:/usr/ports/misc/help2man # gdb `which dialog4ports` dialog4ports.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... Core was generated by `dialog4ports'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libncursesw.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libncursesw.so.8 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/lib/libdialog.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdialog.so.7 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000800fef1fa in kill () from /lib/libc.so.7 (gdb) where #0 0x000800fef1fa in kill () from /lib/libc.so.7 #1 0x000800f8ccae in __stack_chk_fail () from /lib/libc.so.7 #2 0x000800f8cc10 in __stack_chk_fail () from /lib/libc.so.7 #3 0x004029d9 in main () (gdb) Dan ___ 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
dialog4ports stack overflowing recently
I've noticed that dialog4ports has been crashing pretty consistently recently. Happening to anyone else? Dan root@winbsd:/usr/ports/net-mgmt # cd zabbix2-agent/ root@winbsd:/usr/ports/net-mgmt/zabbix2-agent # ls Makefiledialog4ports.core root@winbsd:/usr/ports/net-mgmt/zabbix2-agent # gdb `which dialog4ports` dialog4ports.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Core was generated by `dialog4ports'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libncursesw.so.8...done. Loaded symbols for /lib/libncursesw.so.8 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/lib/libdialog.so.7...done. Loaded symbols for /usr/lib/libdialog.so.7 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000800fedffa in kill () from /lib/libc.so.7 (gdb) where #0 0x000800fedffa in kill () from /lib/libc.so.7 #1 0x000800f8c4c0 in __stack_chk_fail () from /lib/libc.so.7 #2 0x000800f8c430 in __stack_chk_fail () from /lib/libc.so.7 #3 0x004029aa in main (argc=value optimized out, argv=value optimized out) at dialog4ports.c:212 ___ 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: Atom N450 + C3 + HPET == bad timer behaviour
Hi, It's (transcribed): kern.timecounter.hardware: TSC kern.timecounter.choice: TSC(1000) ACPI-fast (900) HPET (950) i8254 (0) dummy(-1000) kern.timecounter.tick: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.smp_tsc: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.tsc_shift: 1 Thanks, Adrian ___ 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: dialog4ports crashing / dumping core
Yep, got it. Sorry for the multiple posts ... we lost power and my mail server switched sites causing a temporary loss of trust between me and the freebsd.org mail servers. Thanks for all the help, Dan On Mon, 24 Jun 2013, Ilya A. Arkhipov wrote: Hi Dan, libdialog was bumped svn commit: r252129 - in head: . gnu/lib/libdialog. ABI was broken, now you should rebuild dialog4ports, it should fix your problem. Sorry for any inconvenience caused. -- With Best Regards, Ilya A. Arkhipov ___ 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 dan -- Dan Mack ___ 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: zfs kernel panic, known incompatibilities with clang CPUTYPE/COPTFLAGS?
On Mon, 24 Jun 2013 12:15:18 +0200 Kristof Provost kris...@sigsegv.be wrote: For what it's worth, I'm running into exactly the same problem. (amd64, stable/9). I have no custom settings in /etc/make.conf or /etc/src.conf I had a short discussion with the maintainer of our stress-test-suite, he was able to create a test-case which triggers the problem. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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
errors building 9-STABLE on recent HEAD
I recently upgraded my main buildbox from an ancient 9.0-STABLE snapshot to head and I've run into an issue building 9-STABLE on it. Initally this was broken by the switch to bmake, but Simon committed a work around that and using the fmake port also works around it. Now I'm seeing a strange error in yacc generated code. I say strange because yacc is correctly being bootstrapped so we're using the expected version and not the one in HEAD. Does anyone have any insight into this issue? cc -O2 -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I. -I/home/bed22/src-9/gnu/usr.bin/binutils/ld -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../libbfd -I/home/bed22/obj/home/bed22/src-9/gnu/usr.bin/binutils/ld/../libbfd -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/include -DTARGET=\x86_64-unknown-freebsd\ -DDEFAULT_EMULATION=\elf_x86_64_fbsd\ -DSCRIPTDIR=\/usr/libdata\ -DBFD_VERSION_STRING=\2.17.50 [FreeBSD] 2007-07-03\ -DBINDIR=\/usr/bin\ -DTARGET_SYSTEM_ROOT=\\ -DTOOLBINDIR=\//usr/bin/libexec\ -D_GNU_SOURCE -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld -I/home/bed22/src-9/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/bfd -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c ldlex.c cc1: warnings being treated as errors stdout: In function 'yy_get_next_buffer': stdout:3229: warning: passing argument 2 of 'yy_input' from incompatible pointer type *** [ldlex.o] Error code 1 Stop in /home/bed22/src-9/gnu/usr.bin/binutils/ld. *** [all] Error code 1 Thanks, Brooks pgpyT6uLOER6I.pgp Description: PGP signature
Re: FreeBSD 2013-Q2 status reports!
On Mon, Jun 17, 2013 at 7:14 PM, Isabell Long iss...@freebsd.org wrote: It's that time again! On behalf of monthly@, I would like to inform you that the next submission date for the April to June quarterly status reports is July 7th, 2013 - less than a month away. Note that you have a little less than 2 weeks left to prepare and send us your reports. They don't have to be very long - anything that lets people know what is going on inside FreeBSD is useful. Note that submission of reports is not restricted to committers - anyone who is doing anything interesting and FreeBSD-related can write one! The preferred and easiest submission method is to use the XML generator linked to from http://www.freebsd.org/news/status/status.html, with the result emailed as an attachment to mont...@freebsd.org. On that page, there is also a link to an XML template which can be filled out manually and attached if preferred. To enable compilation and publication of the Q2 report as soon as possible for the July 7th deadline, please be prompt with any report submissions you may have. I look forward to compiling the report for 2013 Q2. Many thanks, Isabell. (Hat: monthly@) ___ 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
lock order reversal in r252098
Hello- I am running 10.0-CURRENT #0 r252098 on a beaglebone and I am getting the occasional LOR when reading/writing in an nfs mount lock order reversal: 1st 0xc1c0a150 newnfs (newnfs) @ /usr/src/sys/kern/vfs_syscalls.c:4064 2nd 0xc6a5e278 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2311 3rd 0xc1c12150 newnfs (newnfs) @ /usr/src/sys/kern/vfs_subr.c:2099 KDB: stack backtrace: end() at 0xd52035b0 scp=0xd52035b0 rlv=0xc05108e0 (db_trace_self+0x14) rsp=0xd5203498 rfp=0xc057394f Bad frame pointer: 0xc057394f Shortly after, the beaglebone locks up and requires a power cycle If anyone has any hints or can spare some cycles to help me debug this issue, please let me know Many Thanks ___ 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
sysctl -n compat.ia32.maxvmem
Hello list, I was forced to run -CURRENT because no other version booted in my new box. Running 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Wed Jun 12 15:23:10 CDT 2013. I'm getting this: # portupgrade -a make: Mk/Mk/bsd.port.mk line 1638: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi make: /usr/ports/Mk/bsd.port.mk line 1638: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi make: Mk/Mk/bsd.port.mk line 1638: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi make: Mk/Mk/bsd.port.mk line 1638: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem /dev/null 21; then echo YES; fi ... After getting tons of messages like this portupgrade actually works. Sure enough, I do not have COMPAT_FREEBSD32 enabled in kernel, I guess this is what it is about? -- Cheers, Saul ___ 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: Kernel build fails on ARM: Cannot fork: Cannot allocate memory
On Sun, 23 Jun 2013, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 07:50:40PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 08:44:25PM +0400, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 07:16:17PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 06:43:46PM +0400, Ruslan Bukin wrote: Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db bt Tracing pid 1 tid 11 td 0xc547f620 _end() at 0xde9d0530 scp=0xde9d0530 rlv=0xc1211458 (db_trace_thread+0x34) rsp=0xde9d0514 rfp=0xc12d1b60 Bad frame pointer: 0xc12d1b60 db This is completely broken. It seems that witness triggered the panic, and ddb is unable to obtain a backtrace from the normal panic(9) call. Show the output of the 'show alllocks'. No such command Do you have witness in the kernel config ? If not, add it to the config and retry. Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db show alllocks Process 1 (kernel) thread 0xc55fc620 (11) exclusive sleep mutex pmap (pmap) r = 0 (0xc5600590) locked @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:729 exclusive rw pmap pv global (pmap pv global) r = 0 (0xc1479dd0) locked @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:728 shared rw vm object (vm object) r = 0 (0xc1551d4c) locked @ /usr/home/br/dev/head/sys/vm/vm_map.c:1809 exclusive sx vm map (user) (vm map (user)) r = 0 (0xc5600528) locked @ /usr/home/br/dev/head/sys/kern/imgact_elf.c:445 exclusive lockmgr ufs (ufs) r = 0 (0xc56f7914) locked @ /usr/home/br/dev/head/sys/kern/imgact_elf.c:821 exclusive sleep mutex Giant (Giant) r = 0 (0xc147c778) locked @ /usr/home/br/dev/head/sys/kern/vfs_mount.c:1093 db Would any of the arm users be interested in testing a larger patch that changes the way the kernel allocations KVA? It also has some UMA code that lessens kernel memory utilization. http://people.freebsd.org/~jeff/vmem.diff Any reports would be helpful. Is there any ETA on getting stack tracing fixed? I suspect the pmap recursion encountered with Kostik's patch exist in the current kernel. The other changes in this patch my fix that as well. Thanks, Jeff ___ 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
