From owner-freebsd-current Tue Jul 16 12: 7:53 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D50E37B400 for ; Tue, 16 Jul 2002 12:07:50 -0700 (PDT) Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21F4F43E67 for ; Tue, 16 Jul 2002 12:07:50 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24851 invoked from network); 16 Jul 2002 19:07:49 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 16 Jul 2002 19:07:49 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g6GJ7l053891; Tue, 16 Jul 2002 15:07:47 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15668.27229.270084.969951@grasshopper.cs.duke.edu> Date: Tue, 16 Jul 2002 15:07:53 -0400 (EDT) From: John Baldwin To: Andrew Gallatin Subject: Re: VOP_GETATTR panic on Alpha Cc: Andrew Kolchoogin , current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 16-Jul-2002 Andrew Gallatin wrote: > > John Baldwin writes: > > > > > > We need to somehow let only interrupt threads and the panic'ed process > > > run after a panic. I have no idea how to do this in a clean, > > > low-impact way. > > > > It's probably preemption. However, the problem may be that you can't > > switch to the ithread if you just turn preemption on for panics because > > the ithread may already be on the run queue, thus why your earlier patch > > may not have worked. Try to see if it works ok if you turn on preemption > > fully by making the second arg to ithread_schedule() be !cold. FWIW, I > > only have problems with preemption on alphas if I use SMP. > > I think its more than this. I tried unconditionally enabling > premption, and I see no improvement. After a panic, it "wedges", and > I see this : > > db> c > > syncing disks... > done > Uptime: 4m26s > > [halt sent] > Stopped at siointr1+0x198: br zero,siointr1+0x330 > > db> tr > siointr1() at siointr1+0x198 > siointr() at siointr+0x40 > isa_handle_fast_intr() at isa_handle_fast_intr+0x24 > alpha_dispatch_intr() at alpha_dispatch_intr+0xd0 > interrupt() at interrupt+0x110 > XentInt() at XentInt+0x28 > --- interrupt (from ipl 0) --- > critical_exit() at critical_exit+0x20 > _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xc4 > msleep() at msleep+0x2b0 > buf_daemon() at buf_daemon+0x1f4 > fork_exit() at fork_exit+0xe0 > exception_return() at exception_return > --- root of call graph --- > > > So its still stuck in msleep. How is it supposed to get back to > the panic'ed thread if a system thread wakes up and is not allowed to > go back to sleep??? Hmmmmm. Surprised we don't see this on other archs then (or maybe we do...). Probably when we have panic'd (and after we leave the debugger and go into boot() or some such) we should take any non-P_SYSTEM processes off the run queues and then remove the panicstr checks from msleep() and the condition variable wait functions. Perhaps better is to dink around in choosethread() so that if panicstr is set, we throw away any threads get that aren't P_SYSTEM or have the TDF_INPANIC flag set. By throw away, I mean that we just ignore any such threads and loop if we get one we want to throw away. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "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