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... 
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???


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to