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>