public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jos Hulzink <josh@stack.nl>
To: Andrew Morton <akpm@digeo.com>,
	"Grover, Andrew" <andrew.grover@intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: must-fix list, v5
Date: Thu, 22 May 2003 16:23:22 +0200	[thread overview]
Message-ID: <200305221623.22403.josh@stack.nl> (raw)
In-Reply-To: <20030522013101.7181cdb0.akpm@digeo.com>

On Thursday 22 May 2003 10:31, Andrew Morton wrote:
> "Grover, Andrew" <andrew.grover@intel.com> wrote:
> > > From: Andrew Morton [mailto:akpm@digeo.com]
> >
> > Hi just wanted to add some comments below:
>
> Appreciated, thanks.
>
> > >  drivers/acpi/
> > >  ~~~~~~~~~~~~~
> > >
> > >  o davej: ACPI has a number of failures right now.  There are
> >
> > ...
> >
> > Working on these (they're all in bugzilla), more help needed of course
> >
> > :)
>
> OK, well if they're safely bugzilla'd I shall remove them from here.
> Unless you think they're drop-dead stop-ship material.
>
> > > +o mochel: it seems the acpi irq routing code could use a
> > > serious rewrite.
> >
> > No the problem is the ACPI irq routing code is trying to piggyback on
> > the existing MPS-specific data structures, and it's generally a hack. So
> > yes mochel is right, but it is also purging MPS-ities from common code
> > as well. I've done some preliminary work in this area and it doesn't
> > seem to break anything (yet) but a rewrite in this area imho should not
> > be rushed out the door. And, I think the above bugs can be fixed w/o the
> > rewrite.
>
> Where do you think this work sits on the seriousness scale?  Is it
> affecting a lot of people?  Is it a large-scale restructure?

This is what bug 699 is all about I think. As far as I can see, it is a 
serious issue for people with MPS 1.4 systems: The system is unusable due to 
wrong IRQ mappings. MPS 1.4 is used in most (all ?) PPro and PII SMP systems, 
though often can be disabled. I can't say how many systems really rely on MPS 
1.4. Workaround that works for most people is booting with pci=noacpi, though 
I have reports of systems where this isn't the solution. MPS 1.1 systems 
work, though this is more a coincidence than well coded ACPI behaviour.

The amount of people that can't possibly get Linux booting with ACPI enabled 
will not be big. The amount of people that think it's annoying they have to 
disable MPS 1.4 or ACPI to get a running system might be somewhat bigger. My 
box only shuts down with ACPI, and thanks to MPS 1.4 my soundcard doesn't 
glitch when there is heavy SCSI activity. (Onboard SCSI & Soundcard share the 
interrupt when MPS 1.4 is disabled). 

Basically, what happens is that ACPI forgets to look for MPS tables when no 
MADT is found. It assumes the APIC should be set up in PIC mode, though the 
APIC has been rerouted already. As a result, the irq entries in pci_dev are 
filled with the "below 15" values, while the APIC generates "above 15" 
interrupts.

Jos

  reply	other threads:[~2003-05-22 14:03 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-22  8:16 must-fix list, v5 Grover, Andrew
2003-05-22  8:31 ` Andrew Morton
2003-05-22 14:23   ` Jos Hulzink [this message]
     [not found] <20030521152255.4aa32fba.akpm@digeo.com.suse.lists.linux.kernel>
     [not found] ` <20030521152334.4b04c5c9.akpm@digeo.com.suse.lists.linux.kernel>
     [not found]   ` <20030526093717.GC642@zaurus.ucw.cz.suse.lists.linux.kernel>
     [not found]     ` <20030528144839.47efdc4f.akpm@digeo.com.suse.lists.linux.kernel>
     [not found]       ` <20030528215551.GB255@elf.ucw.cz.suse.lists.linux.kernel>
2003-05-29  9:17         ` Andi Kleen
2003-05-29  9:32           ` David S. Miller
2003-05-29  9:46             ` Pavel Machek
2003-05-29 10:01               ` David S. Miller
2003-05-29 10:03                 ` Pavel Machek
2003-05-29  9:46             ` Andi Kleen
2003-05-29 10:01               ` David S. Miller
2003-05-29 11:25             ` Pavel Machek
2003-05-29 11:26               ` David S. Miller
2003-05-29 11:39                 ` Arjan van de Ven
2003-05-29 20:10                   ` Pavel Machek
2003-05-29 20:06             ` Pavel Machek
2003-05-29 21:15               ` David S. Miller
  -- strict thread matches above, loose matches on Subject: below --
2003-05-21 23:59 Arnd Bergmann
2003-05-21 22:22 Andrew Morton
2003-05-21 22:23 ` Andrew Morton
2003-05-21 22:49   ` Tom Rini
2003-05-21 22:55     ` Andrew Morton
2003-05-26  9:37   ` Pavel Machek
2003-05-28 21:48     ` Andrew Morton
2003-05-28 21:55       ` Pavel Machek
2003-05-28 22:06         ` Andrew Morton
     [not found]           ` <20030528221812.GC255@elf.ucw.cz>
2003-05-28 22:46             ` Andrew Morton
2003-05-28 23:03               ` Pavel Machek
2003-05-29 11:13               ` Pavel Machek
2003-05-21 22:41 ` Andrew Morton
2003-05-22  1:03 ` Carl-Daniel Hailfinger
2003-05-22  3:08   ` oxymoron
2003-05-22  1:25 ` Andrew Theurer
2003-05-22  6:24 ` Jens Axboe
2003-05-25 21:05 ` Daniel Jacobowitz

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=200305221623.22403.josh@stack.nl \
    --to=josh@stack.nl \
    --cc=akpm@digeo.com \
    --cc=andrew.grover@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    /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