On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
>
> That makes sense, but ... there are BIOSes that actually list nested
> resources, e.g., http://bugzilla.kernel.org/show_bug.cgi?id=9514#c29 :
>
> [00290 - 00294] Motherboard resources
> [00290 - 0029F] Motherboard resources
He
On Thursday 14 February 2008 04:14:45 pm Linus Torvalds wrote:
>
> On Thu, 14 Feb 2008, Linus Torvalds wrote:
> >
> > It should insert the resource to the root resource (or a bridge resource),
> > or not at all. If somebody else has already inserted a real device
> > resource, we already know a
On Thu, 14 Feb 2008, Linus Torvalds wrote:
>
> It should insert the resource to the root resource (or a bridge resource),
> or not at all. If somebody else has already inserted a real device
> resource, we already know about it, and the PnP information is going to be
> just making things wors
On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
> >
> > [ 22.906610] system 00:08: iomem range 0xfebfe000-0xfebfec00 has been
> > reserved
> > [ 22.906654] system 00:08: iomem range 0xfebfa000-0xfebfac00 has been
> > reserved
>
> The PNP resource fits entirely inside the PCI bus resource, so th
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 re
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:[EMAIL PROTECTED] for
device :00:1b.0
and here is what the
On Thursday 14 February 2008 01:26:59 pm Linus Torvalds wrote:
>
> On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
>
> > On Thursday 14 February 2008 12:42:52 pm Linus Torvalds wrote:
> > >
> > > It *shouldn't* fail.
> > >
> > > Things should fail only when two different drivers have requested the
>
On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
> On Thursday 14 February 2008 12:42:52 pm Linus Torvalds wrote:
> >
> > It *shouldn't* fail.
> >
> > Things should fail only when two different drivers have requested the same
> > region. NOT when something tells the system that a region _exists_.
>
On Thursday 14 February 2008 12:42:52 pm Linus Torvalds wrote:
>
> On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
> >
> > Sorry for the delay. I did work on this, but I don't see how this
> > can work. pcibios_init() marks its reservations as not busy, so the
> > subsequent PNP request doesn't fail,
On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
>
> Sorry for the delay. I did work on this, but I don't see how this
> can work. pcibios_init() marks its reservations as not busy, so the
> subsequent PNP request doesn't fail, even if it clashes.
It *shouldn't* fail.
Things should fail only when t
On Tuesday 05 February 2008 01:12:46 pm Bjorn Helgaas wrote:
> On Tuesday 05 February 2008 11:15:12 am Linus Torvalds wrote:
> > No, you don't need any quirks: you just do an "insert_resource()" and
> > ignore the error return. If the (bogus) PnP resource clashes with the
> > (correct) hardware P
On Feb 5, 2008 12:12 PM, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> I'll play with your insert_resource() idea and see if I can figure
> something out.
Any word on this yet?
Thanks!
--
avuton
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
--
To unsubscribe from this list: s
On Tuesday 05 February 2008 11:15:12 am Linus Torvalds wrote:
>
> On Tue, 5 Feb 2008, Bjorn Helgaas wrote:
> > >
> > > - PnP/ACPI resource allocation *after* it, but before driver loading
> > >(which wll cause new resources to be allocated). This could be
> > >fs_initcall, or whatever
On Tue, 5 Feb 2008, Bjorn Helgaas wrote:
> >
> > - PnP/ACPI resource allocation *after* it, but before driver loading
> >(which wll cause new resources to be allocated). This could be
> >fs_initcall, or whatever (that's what things like "acpi_event_init"
> >already do).
>
> If w
On Feb 4, 2008 11:03 PM, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> Does anybody with this motherboard (or the Supermicro board with
> similar SATA problems) also have Windows on it? I'm curious to
> see how Windows deals with this conflict, e.g., what shows up in
> the device manager?
Sorry, I d
On Monday 04 February 2008 02:16:52 pm Linus Torvalds wrote:
>
> On Mon, 4 Feb 2008, Bjorn Helgaas wrote:
> >
> So where in this would you put the
>
> pcibios_init() -> pcibios_resource_survey()
>
> call (it's a subsys_initcall)?
>
> THAT is the thing that actually registers the PCI resu
On Mon, 4 Feb 2008, Bjorn Helgaas wrote:
>
> I'm sure you're right, but I don't understand why yet. Here's what
> I think is happening; please correct me where I'm going wrong:
>
> 1) enumerate PNP & ACPI devices
> 2) initialize PNP & ACPI drivers
> 2a) register ACPI PCI root bridge d
On Monday 04 February 2008 11:18:09 am Linus Torvalds wrote:
> On Mon, 4 Feb 2008, Bjorn Helgaas wrote:
> >
> > I think the problem here is that the PCI BAR is bigger and spans the
> > region reported by ACPI:
>
> Ok, then it doesn't help that it's not busy.
>
> In that case, the only real fix i
On Mon, 4 Feb 2008, Bjorn Helgaas wrote:
>
> I think the problem here is that the PCI BAR is bigger and spans the
> region reported by ACPI:
Ok, then it doesn't help that it's not busy.
In that case, the only real fix is to simply do the ACPI reservations
*after* PCI probing. Which is what it
On Thursday 31 January 2008 05:50:13 pm Linus Torvalds wrote:
> On Thu, 31 Jan 2008, Robert Hancock wrote:
> >
> > I think so. There was one objection that it introduced a dependency on
> > pnpacpi
> > loading after PCI bus enumeration, though.
> >
> > Linus also suggested that pnpacpi could be
On Thu, 31 Jan 2008, Robert Hancock wrote:
>
> I think so. There was one objection that it introduced a dependency on pnpacpi
> loading after PCI bus enumeration, though.
>
> Linus also suggested that pnpacpi could be marking the resources as "present
> but unused" so that drivers can request t
Andrew Morton wrote:
There was a patch floating around to ignore PnPACPI reservations which
conflict with PCI BARs, which appears to be what's happening in this
case. That patch originally worked for any board, but was later made
specific to a certain Supermicro motherboard which had the sata_n
On Sun, 27 Jan 2008 12:17:17 -0600
Robert Hancock <[EMAIL PROTECTED]> wrote:
> Avuton Olrich wrote:
> > With v2.6.24 my second ALSA sound device stopped working.
> >
> > After bisection it says this was the offending commit.
> >
> > a7839e960675b549f06209d18283d5cee2ce9261 is first bad commit
>
On Mon, 2008-01-28 at 08:50 +1100, Linus Torvalds wrote:
>
> On Sun, 27 Jan 2008, Avuton Olrich wrote:
> >
> > With v2.6.24 my second ALSA sound device stopped working.
>
> Hmm. Why is PnP ACPI called before PCI probing? That seems to be the
> problem here - we should *never* have any firmware
On Sun, 27 Jan 2008, Avuton Olrich wrote:
>
> With v2.6.24 my second ALSA sound device stopped working.
Hmm. Why is PnP ACPI called before PCI probing? That seems to be the
problem here - we should *never* have any firmware allocation block known
hardware BARs, they should only be blocking new
Avuton Olrich wrote:
With v2.6.24 my second ALSA sound device stopped working.
After bisection it says this was the offending commit.
a7839e960675b549f06209d18283d5cee2ce9261 is first bad commit
commit a7839e960675b549f06209d18283d5cee2ce9261
Author: Zhao Yakui <[EMAIL PROTECTED]>
Date: Wed N
With v2.6.24 my second ALSA sound device stopped working.
After bisection it says this was the offending commit.
a7839e960675b549f06209d18283d5cee2ce9261 is first bad commit
commit a7839e960675b549f06209d18283d5cee2ce9261
Author: Zhao Yakui <[EMAIL PROTECTED]>
Date: Wed Nov 28 16:21:21 2007 -08
27 matches
Mail list logo
