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??? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
