Date: Tue, 21 Sep 1999 11:05:48 +0800 From: Peter Wemm <peter@netplex.com.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Mike Smith <mike@smith.net.au>, current@FreeBSD.ORG Subject: Re: 2xPIIIx450 results & NFS results Message-ID: <19990921030548.348691CC5@overcee.netplex.com.au> In-Reply-To: Your message of "Mon, 20 Sep 1999 18:52:57 %2B0200." <23777.937846377@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > 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 :-) Tor Egge's patches are more finely grained than that. They disable the SMI traps when the OS tries to access ports 0x70/0x71 only and leaves the rest of the SMI's alone (including soft off buttons) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au 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?19990921030548.348691CC5>