Wayne Sierke wrote:
On Sun, 2008-01-13 at 03:24 +1030, Wayne Sierke wrote:
I added options MUTEX_PROFILING and options HWPMC_HOOKS but the system
hangs when going multi-user after printing: Entropy harvesting:
interrupts ethernet point_to_point. ^t shows it stuck in dd, ^c brings
out to sysctl [<null>] but I can't get past that and am forced to reset.
I tried rebooting without loading modules which gets around that but
then I can't get xorg to start even after loading nvidia.ko. I've seen
the comment in the NOTES section in MUTEX_PROFILING re modules, does it
mean that I won't be able to use nvidia.ko with this test kernel? If so
perhaps someone could comment on how best to proceed re gathering test
results? i.e. would it be better to just use 'nv' or 'vesa' driver for
now and get mutex stats? Or forgo that and keep 'nvidia' and just use
hwpmc, etc.
Someone replied privately and evidently I didn't make some things clear
about what I did/tried.
After changing the kernel config, I used appropriate incarnations of
'make buildkernel KERNCONF=' and 'make installkernel KERNCONF= KODIR='
and used 'nextboot -k'.
I also tried rebuilding nvidia.ko (including when booted under the
profiling kernel) but not surprisingly the resulting file was identical
to the original.
I've just booted into a kernel with options HWPMC_HOOKS so I'll grab
some results here. Meanwhile I'll prepare a kernel with just options
MUTEX_PROFILING and if I haven't heard anything different in the
meantime, I'll set about checking that out without nvidia.ko.
MUTEX_PROFILING changes the kernel ABI so modules that are not compiled
with that option will not work. If you use make buildkernel to build
your kernel + modules together then it uses the kernel config file for
both so they are compatible, otherwise your modules only are built with
default options. So, if you have any other modules apart from nvidia
then use make buildkernel for those, and add -DMUTEX_PROFILING to the
CFLAGS of the nvidia build and try that. It may still not be enough
since nvidia is a wrapper around a binary module, so you may also need
to revert to nv.
Kris
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
