From owner-freebsd-current Tue May 8 16:48:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 6523737B42C for ; Tue, 8 May 2001 16:48:20 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f48NldG31584; Tue, 8 May 2001 16:47:39 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 08 May 2001 16:46:50 -0700 (PDT) From: John Baldwin To: Dag-Erling Smorgrav Subject: Re: pgm to kill 4.3 via vm Cc: freebsd-current@FreeBSD.org, freebsd-stable@frebsd.org, Kris Kennaway , Dennis Glatting , tlambert2@mindspring.com Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 08-May-01 Dag-Erling Smorgrav wrote: > Terry Lambert 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 -- 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message