linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* (no subject)
@ 2003-08-25 15:57 ak
  0 siblings, 0 replies; only message in thread
From: ak @ 2003-08-25 15:57 UTC (permalink / raw)
  To: paul.devriendt; +Cc: davej, linux-kernel, aj, mark.la

ngsdorf@amd.com, richard.brunner@amd.com, pavel@suse.cz
Subject: Re: Cpufreq for opteron
References: <99F2150714F93F448942F9A9F112634C080EF014@txexmtae.amd.com.suse.lists.linux.kernel>
From: Andi Kleen <ak@suse.de>
Date: 25 Aug 2003 17:57:27 +0200
In-Reply-To: <99F2150714F93F448942F9A9F112634C080EF014@txexmtae.amd.com.suse.lists.linux.kernel>
Message-ID: <p731xv9687s.fsf@oldwotan.suse.de>
Lines: 41
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

paul.devriendt@amd.com writes:

> > -----Original Message-----
> > From: Pavel Machek [mailto:pavel@suse.cz]
> > Sent: Monday, August 25, 2003 8:51 AM
> > To: Devriendt, Paul
> > Cc: davej@redhat.com; linux-kernel@vger.kernel.org; aj@suse.de;
> > Langsdorf, Mark; Brunner, Richard
> > Subject: Re: Cpufreq for opteron
> > 
> > 
> > Hi!
> > 
> > > > 4) given good hardware and debugged driver, will any of those
> > > > BUG_ON()s ever trigger?
> > > 
> > > Only if there are BIOS problems. 
> > 
> > In such case, I believe best idea is to leave them in as BUG_ON(). On
> > broken BIOS, it will kill machine cleanly, and hopefully bios is going
> > to be fixed.
> > 
> > If broken BIOS is seen in retail, we'll need to solve this other way.
> > 
> > Does this seem okay to you?
> 
> My concerns with the BUG_ON() approach are :
>   1. Ease of me debugging the problem, as some of the state data I would
>      want to see is global, so it might not be in a backtrace.
>   2. Taking the machine down when exestuation could continue.
> 
> You have more kernel experience than I do, so I am willing to accept your
> advice. I am ok with it.

I agree with your concerns. I would not back down.

BUG_ON to handle non fatal BIOS issues is just the wrong tool.
BUG_ON is for internal code problems, it is not an appropiate error handler
for external issues (like a broken BIOS)

-Andi

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2003-08-25 15:57 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-25 15:57 ak

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).