Date: Tue, 16 Jul 2002 15:07:53 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Andrew Kolchoogin <andrew@snark.rinet.ru>, current@FreeBSD.org Subject: Re: VOP_GETATTR panic on Alpha Message-ID: <XFMail.20020716150753.jhb@FreeBSD.org> In-Reply-To: <15668.27229.270084.969951@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > <zero=0x0> > 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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020716150753.jhb>