mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Aaron Durbin" <adurbin@google.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Andrew Morton" <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, "Andi Kleen" <ak@suse.de>
Subject: Re: 2.6.18-mm1
Date: Tue, 26 Sep 2006 22:44:39 -0700	[thread overview]
Message-ID: <8f95bb250609262244w423bea15pe15ec6a1c7ef1800@mail.google.com> (raw)
In-Reply-To: <m1ac4lriz5.fsf@ebiederm.dsl.xmission.com>

On 9/26/06, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Andrew Morton <akpm@osdl.org> writes:
>
> > On Tue, 26 Sep 2006 20:04:05 -0600
> > ebiederm@xmission.com (Eric W. Biederman) wrote:
> >
> >> When I apply:
> >> x86_64-mm-insert-ioapics-and-local-apic-into-resource-map
> >>
> >> My e1000 fails to initializes and complains about a bad eeprom checksum.
> >> I haven't tracked this down to root cause yet and I am in the process of
> > building
> >> 2.6.18-mm1 with just that patch reverted to confirm that is the only cause.
> >>
> >> I could not see anything obvious in the patch.  I don't have a clue the patch
> >> could be triggering the problem I'm seeing.
> >>
> >> At a quick visual diff I'm not seeing any other differences in the kernel boot
> >> logs, or in /proc/iomem.
> >
> > This bit looks fishy:
> >
> >  GSI 17 sharing vector 0x4A and IRQ 17
> >  PCI->APIC IRQ transform: 0000:05:0c.0[A] -> IRQ 17
> > +PCI: Cannot allocate resource region 8 of bridge 0000:00:02.0
> > +PCI: Cannot allocate resource region 8 of bridge 0000:01:00.0
> > +PCI: Cannot allocate resource region 8 of bridge 0000:01:00.2
> > +PCI: Cannot allocate resource region 0 of device 0000:01:00.1
> > +PCI: Cannot allocate resource region 0 of device 0000:01:00.3
> > +PCI: Cannot allocate resource region 0 of device 0000:03:04.0
> > +PCI: Cannot allocate resource region 0 of device 0000:03:04.1
> >  PCI-GART: No AMD northbridge found.
> >  PCI: Bridge: 0000:01:00.0
> >    IO window: disabled.
> > -  MEM window: fe000000-fe0fffff
> > +  MEM window: e2000000-e20fffff
> >    PREFETCH window: fd000000-fdffffff
> >  PCI: Bridge: 0000:01:00.2
> >    IO window: 1000-1fff
> > -  MEM window: fe100000-fe1fffff
> > +  MEM window: e2100000-e21fffff
> >    PREFETCH window: disabled.
> >  PCI: Bridge: 0000:00:02.0
> >    IO window: 1000-1fff
> > -  MEM window: fe000000-fe2fffff
> > +  MEM window: e2000000-e22fffff
> >    PREFETCH window: fd000000-fdffffff
> >  PCI: Bridge: 0000:00:06.0
> >    IO window: disabled.
> > @@ -123,17 +131,17 @@
> >  PCI: Bridge: 0000:00:1e.0
> >    IO window: 2000-2fff
> >    MEM window: fb000000-fc0fffff
> > -  PREFETCH window: e2000000-e20fffff
> >
> >
> > Wanna hack into arch/i386/pci/i386.c:pcibios_allocate_bus_resources() and
> > see what is conflicting with what?
>
> Good catch.  Add that to the earlier /proc/iomem output.
> > fe200000-fe200fff : IOAPIC 1
> > fe201000-fe201fff : IOAPIC 2
>
> On that board I have ioapics on pci devices and it appears the way
> the patch is reserving them it doesn't account for ioapics that
> have that property.  I.e.  Those ioapics regions show up in lspci
> on an ioapic pci device and the regions are specified with normal
> base address registers.
>

That patch marks each IOAPIC resource as IORESOURCE_BUSY.  This why
the pci allocation fails. I will post patch to fix this in the
morning.

-Aaron

  reply	other threads:[~2006-09-27  5:44 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-24 11:02 2.6.18-mm1 Andrew Morton
2006-09-24 12:46 ` 2.6.18-mm1 Russell King
2006-09-24 13:11   ` 2.6.18-mm1 Russell King
2006-09-24 13:22   ` 2.6.18-mm1 Petr Baudis
2006-09-24 14:20     ` 2.6.18-mm1 Russell King
2006-09-24 14:29       ` 2.6.18-mm1 Petr Baudis
2006-09-24 14:47         ` 2.6.18-mm1 Russell King
2006-09-24 16:55           ` 2.6.18-mm1 Petr Baudis
2006-09-24 18:48           ` 2.6.18-mm1 Junio C Hamano
2006-09-24 21:34             ` 2.6.18-mm1 Russell King
2006-09-24 21:56               ` 2.6.18-mm1 Andrew Morton
2006-09-24 22:07               ` 2.6.18-mm1 Junio C Hamano
2006-09-24 16:35 ` 2.6.18-mm1 Dmitry Torokhov
2006-09-24 17:06   ` 2.6.18-mm1 Andrew Morton
2006-09-27  2:04 ` 2.6.18-mm1 Eric W. Biederman
2006-09-27  3:11   ` 2.6.18-mm1 Andrew Morton
2006-09-27  5:12     ` 2.6.18-mm1 Eric W. Biederman
2006-09-27  5:44       ` Aaron Durbin [this message]
2006-09-27  6:20         ` 2.6.18-mm1 Eric W. Biederman
2006-09-27  7:13   ` 2.6.18-mm1 Andi Kleen
2006-09-27  7:39     ` 2.6.18-mm1 Eric W. Biederman
2006-09-27  7:51       ` 2.6.18-mm1 Andi Kleen
2006-09-27 14:08         ` 2.6.18-mm1 Eric W. Biederman
2006-09-27 22:06           ` 2.6.18-mm1 Aaron Durbin
2006-09-27 23:06             ` 2.6.18-mm1 Andrew Morton
2006-09-27  9:25 ` 2.6.18-mm1 Andy Whitcroft
2006-09-27 16:12   ` 2.6.18-mm1 Andrew Morton
2006-09-27 16:50     ` 2.6.18-mm1 Andy Whitcroft

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=8f95bb250609262244w423bea15pe15ec6a1c7ef1800@mail.google.com \
    --to=adurbin@google.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=ebiederm@xmission.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

all inboxes | Powered by JetHome®