mutex_owner
All,
Anyone use mutex_owner in a dtrace script, as the obvious does not work
for me:
Content of spin.d:
#!/usr/sbin/dtrace -qs
:::*spin
{
self-mutex = (kmutex_t *) arg0;
self-mutex_owner = mutex_owner((kmutex_t *) :self-mutex);
}
# dtrace -s spin.d
dtrace: failed to compile script spin.d: line 5: mutex_owner( ) argument #1 is i
ncompatible with prototype:
prototype: struct mtx *
argument: kmutex_t *
Dr.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: DTrace built-in variables
I'll give it a try, thanks. On Thu, Mar 8, 2012 at 8:27 AM, Dr. Baud drb...@yahoo.com wrote: Are the build-in variables cpu and curcpu supported in a 8.1-RELEASE DTrace? Dr. Unfortunately not. However, you can approximate them with (IIRC) curthread-td_oncpu. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
DTrace built-in variables
Are the build-in variables cpu and curcpu supported in a 8.1-RELEASE DTrace? Dr. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
vm.phys_free
Can someone explain exactly what phys_free is telling me, I understand the three pools (DEFAULT, DIRECT and CACHE) and 13 orders of pages. But what does lcnt represent? [root@sn12 ~]# sysctl vm.phys_free vm.phys_free: FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 | POOL 2 ---- -- -- -- -- -- -- 12 ( 16384K) | 12 | 0 | 6 11 ( 8192K) | 15 | 0 | 26 10 ( 4096K) | 39 | 0 | 38 9 ( 2048K) | 49 | 2 | 72 8 ( 1024K) | 29 | 1 | 137 7 ( 512K) | 41 | 1 | 231 6 ( 256K) | 74 | 0 | 332 5 ( 128K) | 127 | 1 | 448 4 (64K) | 149 | 4 | 725 3 (32K) | 278 | 13 | 980 2 (16K) | 388 | 36 |1290 1 ( 8K) | 213 | 200 |1831 0 ( 4K) | 0 | 627 |2865 Dr. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: spontaneous reboot - ptrace
As it happens the NMI was caused by attempting to access memory mapped PCI address space. The HBA associated with the mapped PCI address space generated a PERR. Thanks for the help. - Original Message From: Kostik Belousov kostik...@gmail.com To: Dr. Baud drb...@yahoo.com Cc: freebsd-hackers@freebsd.org Sent: Fri, February 18, 2011 6:21:36 AM Subject: Re: spontaneous reboot - ptrace On Fri, Feb 18, 2011 at 03:58:05AM -0800, Dr. Baud wrote: First, do you have a console output during the run ? Is it possible that machine paniced ? If not, were there any kernel messages before reboot ? Second, what is the process you are dumping ? Can you show at least the procstat -v pid output for the process ? Sorry for this late response but my earlier response appears to have been consumed by the email reflector. I'm getting an NMI. And the trouble appears to be when trying to read via ptrace memory segments of type KVME_TYPE_DEVICE. The app in quesion allocates a large number of large memory buffers and maps them into virtual address space. Not all segments cause the NMI however. Small sampling of the virtual memory map. You did not provided exact console output on the panic, despite requested. What is the device that was mmaped ? Obviously, this is your problem. Can you gather all required information ? PID STARTEND PRT RES PRES REF SHD FL TP PATH 931 0x40 0x1773000 r-x 4239 5053 2 1 CN vn /mnt/dia g/problemchild 931 0x1872000 0x2ef2000 rw- 4160 1 0 C- vn /mnt/dia g/problemchld 931 0x2ef2000 0x670 rw- 117650 1 0 C- df 9310x8018720000x8018a2000 r-x 480 57 28 CN vn /libexec /ld-elf.so.1 9310x8018a20000x8018b3000 rw- 150 1 0 C- df 9310x8018b30000x801924000 rw- 1130 1698 0 -- dv 9310x8019240000x801925000 rw-10 1698 0 -- dv 9310x8019250000x801926000 rw-10 1698 0 -- dv 9310x8019260000x801927000 rw-10 1698 0 -- dv 9310x8019270000x801928000 rw-10 1698 0 -- dv 9310x8019280000x80192a000 rw-20 1698 0 -- dv 9310x80192a0000x80192b000 rw-10 1698 0 -- dv 9310x80192b0000x80192c000 rw-10 1698 0 -- dv 9310x80192c0000x80192d000 rw-10 1698 0 -- dv 9310x80192d0000x80192e000 rw-10 1698 0 -- dv 9310x80192e0000x80193 rw-20 1698 0 -- dv 9310x801930x801932000 rw-20 1698 0 -- dv 9310x8019320000x801993000 rw- 970 1698 0 -- dv 9310x8019930000x8019a rw- 130 1698 0 -- dv 9310x8019a0x8019a1000 rw-10 1698 0 -- dv 9310x802ab70000x802bb7000 ---00 1 0 CN df 9310x0x802bb700x0x802bd6000 rw- 170 1 0 C- vn /lib/lib c.so.7 9310x802bd60000x802bf1000 rw- 180 1 0 C- df 9310x802bf10000x802bfd000 r-x9 14 2 1 CN vn /lib/lib gcc_s.so.1 9310x802bfd0000x802cfc000 ---00 1 0 CN df 9310x802cfc0000x802cfe000 rw-20 1 0 CN vn /lib/lib gcc_s.so.1 9310x802cfe0000x802cff000 rw-10 1698 0 -- dv 9310x802cff0000x802d0 rw-10 1698 0 -- dv 9310x802d00x802e0 rw- 1320 1 0 C- df 9310x802e00x802f0 rw- 1090 1 0 C- df 9310x802f00x802f91000 rw- 1450 1698 0 -- dv 9310x802f910000x802fb2000 rw- 330 1698 0 -- dv 9310x802fb20000x802fd3000 rw- 330 1698 0 -- dv 9310x802fd30000x802ff5000 rw- 340 1698 0 -- dv 9310x802ff50000x802ff6000 rw-10 1698 0 -- dv ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Super pages
In general, is it unadvisable to disable super pages? Dr. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Super pages
On 23/02/2011 14:03, Dr. Baud wrote:
In general, is it unadvisable to disable super pages?
I don't think there would be any effect on the stability of operation if
you disable superpages, but generally (except in cases of CPU bugs) you
would not need to. Your system should operate a bit faster with
superpages enabled.
When is the memory allocated via contigmalloc freed? I have a test kernel
module that allocates memory in 8MB chucks until contigmalloc says enough (the
ginormous.c/Makefile attachment). I also have a bash script that displays the
interesting memory related kernel state variables (the mem attachement).
When I load and unload the kernel module and display the VM pages stats I
never see the wired pages nor free pages change:
vm.pmap.pg_ps_enabled: 1
SYSTEM MEMORY INFORMATION:
mem_phys:= 2138693632 ( 2039MB)Physical memory tunable
mem_user:= 2107297792 ( 2009MB)User space memory available
mem_real:= 2146893824 ( 2047MB)Maximum physical pages
mem_all: = 2075402240 ( 1979MB) [100%] Virual memory pages
mem_cache: =0 ( 0MB) [ 0%] Cached: almost avail. to allocat
mem_inactive:= 7360512 ( 7MB) [ 0%] Inactive: recently unreferenced
mem_active: + 8765440 ( 8MB) [ 0%] Active: recently referenced
mem_wire: 31395840 ( 29MB) [ 1%] Wired: disabled for paging out
mem_free:+ 2027589632 ( 1933MB) [ 97%] Free: fully available
-- ---
mem_hw: = 2147483648 ( 2048MB)Virual memory (cached, etc.)
kldload /sys/modules/ginormous/ginormous.ko
Ginormous module loading
Ginormous contigmalloc failed(229):
SYSTEM MEMORY INFORMATION:
mem_phys:= 2138693632 ( 2039MB)Physical memory tunable
mem_user:=180330496 (171MB)User space memory available
mem_real:= 2146893824 ( 2047MB)Maximum physical pages
mem_all: = 2075402240 ( 1979MB) [100%] Virual memory pages
mem_cache: = 22237184 ( 21MB) [ 1%] Cached: almost avail. to allocat
mem_inactive:= 253952 ( 0MB) [ 0%] Inactive: recently unreferenced
mem_active: + 2387968 ( 2MB) [ 0%] Active: recently referenced
mem_wire:1958363136 ( 1867MB) [ 94%] Wired: disabled for paging out
mem_free:+ 91795456 ( 87MB) [ 4%] Free: fully available
-- ---
mem_hw: = 2147483648 ( 2048MB)Virual memory (cached, etc.)
kldunload ginormous
Ginormous module unloading
Warning: memory type GINORMOUS leaked memory on destroy (229 allocations,
1920991232 bytes leaked).
SYSTEM MEMORY INFORMATION:
mem_phys:= 2138693632 ( 2039MB)Physical memory tunable
mem_user:=180314112 (171MB)User space memory available
mem_real:= 2146893824 ( 2047MB)Maximum physical pages
mem_all: = 2075402240 ( 1979MB) [100%] Virual memory pages
mem_cache: = 21565440 ( 20MB) [ 1%] Cached: almost avail. to allocat
mem_inactive:= 413696 ( 0MB) [ 0%] Inactive: recently unreferenced
mem_active: + 2842624 ( 2MB) [ 0%] Active: recently referenced
mem_wire:1958379520 ( 1867MB) [ 94%] Wired: disabled for paging out
mem_free:+ 91807744 ( 87MB) [ 4%] Free: fully available
-- ---
mem_hw: = 2147483648 ( 2048MB)Virual memory (cached, etc.)
Note that this behavior occurs whether superpages are enabled or not.
Anyone
have
and explanation?
Dr.
#include sys/types.h
#include sys/module.h
#include sys/malloc.h
#include sys/systm.h /* uprintf */
#include sys/param.h /* defines used in kernel.h */
#include sys/kernel.h /* types used in module initialization */
#include sys/conf.h /* cdevsw struct */
MALLOC_DEFINE(M_GINORMOUS, GINORMOUS, Ginormous Kernel Module);
#define BUFSIZE (8*1024*1024)
#define NMALLOCS 241
static int
ginormous_loader(struct module *m, int what, void *arg)
{
int err = 0;
void *mem[NMALLOCS];
switch (what)
{
case MOD_LOAD:/* kldload */
{
int i;
printf(Ginormous module loading\n);
for (i = 0; i NMALLOCS; i++) {
if ((mem[i] = contigmalloc( BUFSIZE,
M_GINORMOUS,
0,
0UL,
~0UL,
PAGE_SIZE,
0)) == NULL) {
printf(Ginormous contigmalloc failed(%d):\n, i);
break;
}
}
}
break;
case MOD_UNLOAD:
printf(Ginormous module unloading\n);
break;
default:
err = EINVAL;
break;
}
return(err);
}
DEV_MODULE(ginormous, ginormous_loader, NULL);
Makefile
Description
spontaneous reboot - ptrace
First, do you have a console output during the run ? Is it possible that machine paniced ? If not, were there any kernel messages before reboot ? Second, what is the process you are dumping ? Can you show at least the procstat -v pid output for the process ? Sorry for this late response but my earlier response appears to have been consumed by the email reflector. I'm getting an NMI. And the trouble appears to be when trying to read via ptrace memory segments of type KVME_TYPE_DEVICE. The app in quesion allocates a large number of large memory buffers and maps them into virtual address space. Not all segments cause the NMI however. Small sampling of the virtual memory map. PID STARTEND PRT RES PRES REF SHD FL TP PATH 931 0x40 0x1773000 r-x 4239 5053 2 1 CN vn /mnt/dia g/problemchild 931 0x1872000 0x2ef2000 rw- 4160 1 0 C- vn /mnt/dia g/problemchld 931 0x2ef2000 0x670 rw- 117650 1 0 C- df 9310x8018720000x8018a2000 r-x 480 57 28 CN vn /libexec /ld-elf.so.1 9310x8018a20000x8018b3000 rw- 150 1 0 C- df 9310x8018b30000x801924000 rw- 1130 1698 0 -- dv 9310x8019240000x801925000 rw-10 1698 0 -- dv 9310x8019250000x801926000 rw-10 1698 0 -- dv 9310x8019260000x801927000 rw-10 1698 0 -- dv 9310x8019270000x801928000 rw-10 1698 0 -- dv 9310x8019280000x80192a000 rw-20 1698 0 -- dv 9310x80192a0000x80192b000 rw-10 1698 0 -- dv 9310x80192b0000x80192c000 rw-10 1698 0 -- dv 9310x80192c0000x80192d000 rw-10 1698 0 -- dv 9310x80192d0000x80192e000 rw-10 1698 0 -- dv 9310x80192e0000x80193 rw-20 1698 0 -- dv 9310x801930x801932000 rw-20 1698 0 -- dv 9310x8019320000x801993000 rw- 970 1698 0 -- dv 9310x8019930000x8019a rw- 130 1698 0 -- dv 9310x8019a0x8019a1000 rw-10 1698 0 -- dv 9310x802ab70000x802bb7000 ---00 1 0 CN df 9310x0x802bb700x0x802bd6000 rw- 170 1 0 C- vn /lib/lib c.so.7 9310x802bd60000x802bf1000 rw- 180 1 0 C- df 9310x802bf10000x802bfd000 r-x9 14 2 1 CN vn /lib/lib gcc_s.so.1 9310x802bfd0000x802cfc000 ---00 1 0 CN df 9310x802cfc0000x802cfe000 rw-20 1 0 CN vn /lib/lib gcc_s.so.1 9310x802cfe0000x802cff000 rw-10 1698 0 -- dv 9310x802cff0000x802d0 rw-10 1698 0 -- dv 9310x802d00x802e0 rw- 1320 1 0 C- df 9310x802e00x802f0 rw- 1090 1 0 C- df 9310x802f00x802f91000 rw- 1450 1698 0 -- dv 9310x802f910000x802fb2000 rw- 330 1698 0 -- dv 9310x802fb20000x802fd3000 rw- 330 1698 0 -- dv 9310x802fd30000x802ff5000 rw- 340 1698 0 -- dv 9310x802ff50000x802ff6000 rw-10 1698 0 -- dv ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
spontaneous reboot - ptrace
I've an interesting anomaly I'd appreciate some help with. As a result of looking at a threading problem I modified gcore to dump all memory segments associated with a process; basically comment out the Ignore conditional in readmap(). The result is that the box spontaneously reboots sometime Between 40 and 50 seconds into the dump; this is an application that is indeed a memory hog. I commented out the actual write to disk and the result is the same. I’ve even disabled the watchdog to no avail. This is a vanilla 8.1 install: FreeBSD pollyanna 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 running on fairly vanilla hardware: CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3212.93-MHz K8-class CPU) Origin = GenuineIntel Id = 0xf49 Family = f Model = 4 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,DTES64,MON,DS_CPL,CNXT-ID,CX16,xTPR AMD Features=0x2800SYSCALL,LM AMD Features2=0x1LAHF TSC: P-state invariant Any thoughts on how to proceed? Dr. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Driver memory allocation
Is there a cap on the amount of memory a driver (via bus_dmamem_alloc) can allocate, other than the obvious physical memory limit minus the memory already allocated? Dr. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Contiguous physical memory
Can anyone suggest a method/formula to monitor contiguous physical memory allocations such that one could predict when contigmalloc(), make that bus_dmamem_alloc might fail? Dr ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
virtual memory question
Should I be able to recover the physical address of a memory region allocated by configmalloc in a kernel module and mapped to a virtual address by a user application? Dr ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
debug libraries
Apologies if this is the wrong list Are there prepackaged debug versions of the system libraries available (like 'yum install *-debuginfo' in Fedora and 'apt-get install *-dbg' in Ubuntu)? Dr ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
