[no subject]

[ak]

ngsdorf@xxxxxxx, richard.brunner@xxxxxxx, pavel@xxxxxxx
Subject: Re: Cpufreq for opteron
References: <99F2150714F93F448942F9A9F112634C080EF014@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
From: Andi Kleen <ak@xxxxxxx>
Date: 25 Aug 2003 17:57:27 +0200
In-Reply-To: <99F2150714F93F448942F9A9F112634C080EF014@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Message-ID: <p731xv9687s.fsf@xxxxxxxxxxxxxxxx>
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@xxxxxxx writes:

> > -----Original Message-----
> > From: Pavel Machek [mailto:pavel@xxxxxxx]
> > Sent: Monday, August 25, 2003 8:51 AM
> > To: Devriendt, Paul
> > Cc: davej@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; aj@xxxxxxx;
> > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/