Date: Mon, 20 Sep 1999 18:52:57 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Mike Smith <mike@smith.net.au> Cc: current@FreeBSD.ORG Subject: Re: 2xPIIIx450 results & NFS results Message-ID: <23777.937846377@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 20 Sep 1999 09:39:28 PDT." <199909201639.JAA32335@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199909201639.JAA32335@dingo.cdrom.com>, Mike Smith writes: >> >Use a watchdog timeout like you should for any device that may hang. >> >Don't waste time running it every clock tick. >> > >> >ISTR that we thought that the bug might be caused by a bug in unwanted >> >SMI interrupt handling. >> >> If anybody can reproduce this reliably on a *BX chipset I have >> code that will block SMI interrupts we can test with... > >I'm not sure I follow what the alleged problem is here; who is handling >the "unwanted" SMIs? If it's the BIOS, the last thing you want to do >is block all SMIs. The problem is that the RTC stalls. It is suspected that it could be long SMI durations which is responsible for this. To confirm the diagnosis disabling SMI is feasible. You system will not blow up if you disable SMI, I have a system happily chugging away here with SMI disabled for a month. Doing so even idiot-proofs the soft-off button :-) -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! 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?23777.937846377>