mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: paul.devriendt@amd.com
To: pavel@suse.cz
Cc: davej@redhat.com, linux-kernel@vger.kernel.org, aj@suse.de,
	mark.langsdorf@amd.com, richard.brunner@amd.com
Subject: RE: Cpufreq for opteron
Date: Mon, 25 Aug 2003 09:09:26 -0500	[thread overview]
Message-ID: <99F2150714F93F448942F9A9F112634C080EF014@txexmtae.amd.com> (raw)

> -----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.

Thanks. Paul.

> 								Pavel
> -- 
> When do you have a heart between your knees?
> [Johanka's followup: and *two* hearts?]
> 


             reply	other threads:[~2003-08-25 14:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-25 14:09 paul.devriendt [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-08-27  0:43 paul.devriendt
2003-08-27  5:13 ` Dominik Brodowski
2003-08-25 12:53 paul.devriendt
2003-08-25 13:51 ` Pavel Machek
     [not found] <99F2150714F93F448942F9A9F112634C080EF006@txexmtae.amd.com.suse.lists.linux.kernel>
     [not found] ` <20030825084616.GC403@elf.ucw.cz.suse.lists.linux.kernel>
2003-08-25 10:56   ` Andi Kleen
2003-08-24 15:31 paul.devriendt
2003-08-25  9:35 ` Pavel Machek
2003-08-22 20:09 paul.devriendt
2003-08-25  8:46 ` Pavel Machek
2003-08-25 13:30   ` Valdis.Kletnieks
2003-08-22 16:25 Andi Kleen
2003-08-22 13:59 Pavel Machek
2003-08-22 14:43 ` Dave Jones
2003-08-22 19:55   ` Pavel Machek
2003-08-22 20:05   ` Pavel Machek
2003-08-26 23:02     ` Dominik Brodowski
2003-08-22 14:52 ` Christoph Hellwig
2003-08-22 14:55   ` Dave Jones
2003-08-22 19:54   ` Pavel Machek
2003-08-23  7:55     ` Rogier Wolff
2003-08-23 17:50       ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=99F2150714F93F448942F9A9F112634C080EF014@txexmtae.amd.com \
    --to=paul.devriendt@amd.com \
    --cc=aj@suse.de \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.langsdorf@amd.com \
    --cc=pavel@suse.cz \
    --cc=richard.brunner@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®