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
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
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
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 |
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo
