From owner-freebsd-current Tue Jul 16 11:48:32 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 9C25037B400; Tue, 16 Jul 2002 11:48:28 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4C0A43E3B; Tue, 16 Jul 2002 11:48:27 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id OAA22371; Tue, 16 Jul 2002 14:48:27 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g6GIlv551946; Tue, 16 Jul 2002 14:47:57 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15668.27229.270084.969951@grasshopper.cs.duke.edu> Date: Tue, 16 Jul 2002 14:47:57 -0400 (EDT) To: John Baldwin Cc: current@FreeBSD.org, Andrew Kolchoogin Subject: Re: VOP_GETATTR panic on Alpha In-Reply-To: References: <15668.23528.719956.574605@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 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??? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message