Hi,
Can anyone give me a clue, how one can ``stop'' system from accessing RAM, and
then allow it again?
What I want to manage is ``RAM test on demand''.
I just need a point where should I start, or rather in general terms how can I
freeze system for a while to make that test.
I am very new i
Hi,
Can anyone give me a clue, how one can ``stop'' system from accessing RAM, and
then allow it again?
What I want to manage is ``RAM test on demand''.
I just need a point where should I start, or rather in general terms how can I
freeze system for a while to make that test.
I am very new i
Hey,
As I had recently purchased a new MacBook Pro, I have one of the
brand new shiny ones with the Santa Rosa chipset.
I have been trying to run FreeBSD 7.0-BETA1.5 and 8.0-SURPRISE on it,
and everything goes well except the following issues:
1. Sometimes it will hang for ever on the ACP
> Can anyone give me a clue, how one can ``stop'' system from accessing RAM,
> and then allow it again?
I think this has no aim, RAM tests should be done during booting, but
u could try to disable interrupts while in kernel mode 'cli' which
will prevent any further context switching, then try to
On 10/24/07, Patrick Dung <[EMAIL PROTECTED]> wrote:
> Hi
>
> I have ZFS (and snapshot) mounted.
> Then shutdown by `shutdown -p now`.
>
> There is the dump:
>
> # kgdb /boot/kernel/kernel.symbols vmcore.0
> [GDB will not be able to debug user-mode threads:
> /usr/lib/libthread_db.so: Undefined sym
On Tue, Oct 30, 2007 at 08:56:13AM -0700, Bert JW Regeer wrote:
[...]
>
> 2. The Marvell Gigbit NIC is not yet supported. I can provide output
> from pciconf -lv if need be, let me know. Have not yet tried the
> if_myk driver from Marvell themselves.
>
I'm interested in adding support
6 matches
Mail list logo