On 08-May-01 Dag-Erling Smorgrav wrote:
> Terry Lambert <[EMAIL PROTECTED]> writes:
>> So now the question becomes "what is he testing that is
>> resulting in 4.3 locking up?".
>
> Good question. It does some non-trivial stuff besides allocating:
> buffered I/O and fork()/exec()'ing sync(1).
>
>> Your suggested replacement test might be fun to run, but I
>> think it wouldn't lock up 4.3...
>
> Nope. But the attached - much nastier - program did trash my -CURRENT
> box when run as root in an xterm. What happened was that the X server
> faulted and died, rendering the console unusable; the serial console
> filled up with getswapspace() errors, so the only recourse was a break
> to DDB followed by 'call boot', which managed to sync all filesystems
> except the root, but failed to actually reboot the machine.
>
> I would *love* to have a DDB equivalent to 'kill -9', so I could drop
> to the DDB prompt, check ps, kill a process or two, and drop back out
> of DDB. It would have saved me a reboot and a longish fsck in this
> case.
That's easy enough. Well, it used to be at least. You can use 'ps' to find
the address of the struct proc (first pointer in the display) and then do
'call psignal(addr, 9)' to send SIGKILL to the process. Then hit 'c' to
continue and voila, the process dies. I think that may panic now due to proc
lock not being held (though the debugger shouldn't need any locks in theory.)
Perhaps mtx_assert() should honor db_active and not panic if it is set.
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
