Date: Mon, 21 Sep 1998 04:33:06 +1000 From: Bruce Evans <bde@zeta.org.au> To: jhay@mikom.csir.co.za, jkh@time.cdrom.com Cc: current@FreeBSD.ORG, gibbs@plutotech.com, kato@ganko.eps.nagoya-u.ac.jp, mantar@netcom.com Subject: Re: [CAM] Broken tagged queuing drive? Message-ID: <199809201833.EAA31365@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>I also see it here on my dual P5 machine. It seems to be caused by the
>latest version of isa/clock.c. If I go to the previous version (while
>keeping the rest of the source the same), the panic disappear. It only
>happens on the dual P5 machine, the 486 runs happily with the latest
>version of isa/clock.c.
Apparently it wasn't safe to use disable_intr()/enable_intr() under
SMP, or SMP locking doesn't nest properly :(. The interrupt nesting is:
clock interrupt -> normal interrupt masking, whatever that is for SMP
...
disable cpu interrupts (known to be enabled to begin with)
lock clock
sometimes:
i8254_get_timecount() -> save cpu interrupt mask
disable cpu interrupts (nop)
lock clock (oops?)
...
unlock clock
restore cpu interrupt mask
unlock clock <- return
enable cpu interrupts
i8254_get_timecount(), getit() and set_timer_freq() are supposed to be
callable with interrupts disabled. Apparently this never worked.
It's probably unnecessary to lock the clock in clkintr() - the giant
lock suffices. I should never have suggested turning disable_intr()
into a macro to hide the locking.
Bruce
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?199809201833.EAA31365>