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 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: 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 #include #include #include /* uprintf */ #include /* defines used in kernel.h */ #include /* types used in module initialization */ #include/* 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, gin
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: 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 To: Dr. Baud 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 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"
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 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=0xbfebfbff Features2=0x641d AMD Features=0x2800 AMD Features2=0x1 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"