mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Helge Hafting <helgehaf@aitel.hist.no>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>, linux-kernel@vger.kernel.org
Subject: Re: The buggy APIC of the Abit BP6
Date: Thu, 20 Jun 2002 14:21:16 +0200	[thread overview]
Message-ID: <3D11C8BC.5A14379C@aitel.hist.no> (raw)
In-Reply-To: <Pine.GSO.3.96.1020619144446.15094G-100000@delta.ds2.pg.gda.pl>

"Maciej W. Rozycki" wrote:
> 
> On Tue, 18 Jun 2002, Robbert Kouprie wrote:
> 
> > Problem now is, in the ack_none function we only know about the
> > (illegal) vector we are getting, and not about the interrupt we need to
> > reset. Could there be some kind of link between these, so that
> > kick_IO_APIC_irq can be called from there?
> 
>  You get an invalid vector delivered due to massive transmission errors at
> the inter-APIC bus.  The errors are a serious hardware problem that cannot
> and should not be fixed in software.

Yes, the hardware is at fault.  I don't have money for 
other hardware though, so working around it seems a good idea.  

We could simplify the IDE driver a lot by dropping support for
all the broken controllers too. Or tell
people to not use DMA on them.


Of course such an option should default to OFF, and
perhaps live under "dangerous."  It can keep the
BP6 going much longer, which is good enough
for a home machine.

Failing due to a stuck NIC after one week seems worse
than crashing due to a scrambled IPI after some months.
There are more interrupts than IPI's.

This sort of fix don't really make things worse, the 
theoretical scrambled IPI will happen without it too.
The safe solution is NOAPIC, this fix simply makes it work
for a longer time using the bad apic.
 
> 
>  I'm told getting a better PSU may help, though.
Unfortunately not.  I got a nice PSU when I ordered the BP6, 
thinking that power was the only issue. (It was the only
cheap dual solution at the time.)

Helge Hafting

  parent reply	other threads:[~2002-06-20 12:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-12 22:33 Robbert Kouprie
2002-06-13  9:05 ` Helge Hafting
2002-06-13 13:30   ` Robbert Kouprie
2002-06-14 10:54     ` Helge Hafting
2002-06-18 15:30       ` Robbert Kouprie
2002-06-18 15:17         ` Zwane Mwaikambo
2002-06-19 12:47         ` Maciej W. Rozycki
2002-06-19 13:23           ` Robbert Kouprie
2002-06-19 14:03             ` Keith Owens
2002-06-19 14:35               ` Maciej W. Rozycki
2002-06-20  1:50               ` Robbert Kouprie
2002-06-19 14:22             ` Maciej W. Rozycki
2002-06-20 12:21           ` Helge Hafting [this message]
2002-06-20 13:10             ` Maciej W. Rozycki
2002-06-21 13:02               ` Helge Hafting
2002-06-20 22:29             ` Kevin Krieser
2002-06-14 15:07 ` Raphael Manfredi
2002-06-14 16:49 Robbert Kouprie
2002-06-14 18:41 ` Raphael Manfredi
2002-06-18  7:33   ` Helge Hafting
2002-06-18  9:53 Robbert Kouprie

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=3D11C8BC.5A14379C@aitel.hist.no \
    --to=helgehaf@aitel.hist.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@ds2.pg.gda.pl \
    /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®