mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Robert Hancock <hancockr@shaw.ca>,
	Andrew Morton <akpm@linux-foundation.org>,
	avuton@gmail.com, yakui.zhao@intel.com, shaohua.li@intel.com,
	trenn@suse.de,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	alsa-devel@alsa-project.org
Subject: Re: a7839e96 (PNP: increase max resources) breaks my ALSA intel8x0 sound card
Date: Thu, 14 Feb 2008 15:28:52 -0700	[thread overview]
Message-ID: <200802141528.53446.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <alpine.LFD.1.00.0802141323130.6110@woody.linux-foundation.org>

On Thursday 14 February 2008 02:37:15 pm Linus Torvalds wrote:
> 
> On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
> > 
> > That means the PNP system driver has to be registered after the PCI
> > driver.
> 
> After the PCI *subsystem*
> 
> Here's the actual problem:
> 
> [   31.133141] PCI: Unable to reserve mem region #1:4000@febf8000 for device 0000:00:1b.0
> 
> and here is what the resource tree *should* look like:
> 
> 	febf8000-febfbfff : 0000:00:1b.0
> 	  febf8000-febfbfff : ICH HD audio
> 
> that's with a working sound driver.
> 
> Notice how there is *two* resources there: there's the PCI bus resource 
> itself, the one called 0000:00:1b.0 (which was active at boot), and there 
> is the "driver resource" that nests inside of it ("ICH HD audio").
> 
> The PCI bus resource is created and inserted into the resource when the 
> PCI bus discovery happens - long before the driver comes along at all.
> 
> And the problem is this ABSOLUTE CRAP that happened much earlier:
> 
> [   22.906610] system 00:08: iomem range 0xfebfe000-0xfebfec00 has been reserved
> [   22.906654] system 00:08: iomem range 0xfebfa000-0xfebfac00 has been reserved
> 
> which happens
>  (a) before the PCI bus probing

I don't think so.  pci_scan_bus_parented() happened earlier, here:

[   22.875359] ACPI: PCI Root Bridge [PCI0] (0000:00)

and pcibios_init() is a subsys_initcall() that happens before the PNP
system driver registers via fs_initcall() (I had this order wrong in a
previous email).

> This has everything to do with the fact that the PnP layer is  a piece of 
> crap and overrides/messes with the *correct* resources that we found 
> during PCI bus probing.

There are clearly problems with PNP.  I'm trying to help improve the
situation.

> So here is (for the *fifth* time) what PnP should do:
> 
>  - only try to insert its resources *after* the PCI bus probing has 
>    happened

That already happens.

>  - and if that fails, LET THE CRAP FAIL instead of making the *good* code 
>    fail!

The PNP resource fits entirely inside the PCI bus resource, so the PNP
insertion will only fail if the sound driver has already been loaded.

It seems like we're talking past each other.  Would anybody else like
to step in and help explain this to me?  Maybe a fresh viewpoint will
help me find a clue.

Bjorn

  reply	other threads:[~2008-02-14 22:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.Kmpf0B4W44W1VefIME7+BnfUouY@ifi.uio.no>
2008-01-27 18:17 ` Robert Hancock
2008-01-31 22:58   ` Andrew Morton
2008-02-01  0:14     ` Robert Hancock
2008-02-01  0:50       ` Linus Torvalds
2008-02-04 17:39         ` Bjorn Helgaas
2008-02-04 18:18           ` Linus Torvalds
2008-02-04 20:41             ` Bjorn Helgaas
2008-02-04 21:16               ` Linus Torvalds
2008-02-05  7:03                 ` Bjorn Helgaas
2008-02-05 16:46                   ` Avuton Olrich
2008-02-05 18:15                   ` Linus Torvalds
2008-02-05 20:12                     ` Bjorn Helgaas
2008-02-13 22:33                       ` Avuton Olrich
2008-02-14 18:51                       ` Bjorn Helgaas
2008-02-14 19:42                         ` Linus Torvalds
2008-02-14 20:07                           ` Bjorn Helgaas
2008-02-14 20:26                             ` Linus Torvalds
2008-02-14 21:01                               ` Bjorn Helgaas
2008-02-14 21:37                                 ` Linus Torvalds
2008-02-14 22:28                                   ` Bjorn Helgaas [this message]
2008-02-14 22:57                                     ` Linus Torvalds
2008-02-14 23:14                                       ` Linus Torvalds
2008-02-15  0:13                                         ` Bjorn Helgaas
2008-02-15  0:40                                           ` Linus Torvalds
2008-02-27 17:43                                             ` Bjorn Helgaas
2008-01-27 14:40 Avuton Olrich
2008-01-27 21:50 ` Linus Torvalds
2008-01-28  1:15   ` Shaohua Li

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=200802141528.53446.bjorn.helgaas@hp.com \
    --to=bjorn.helgaas@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=avuton@gmail.com \
    --cc=hancockr@shaw.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaohua.li@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=trenn@suse.de \
    --cc=yakui.zhao@intel.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®