public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, Andi Kleen <ak@suse.de>,
	adurbin@google.com
Subject: Re: 2.6.18-mm1
Date: Tue, 26 Sep 2006 23:12:14 -0600	[thread overview]
Message-ID: <m1ac4lriz5.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20060926201104.1bb1a193.akpm@osdl.org> (Andrew Morton's message of "Tue, 26 Sep 2006 20:11:04 -0700")

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.

I'm trying to finish up my msi work, so I'm going to avoid further
digging.  Hopefully this is enough now that we have a reasonable
explanation someone can actually dig in and fix this problem.

Eric



  reply	other threads:[~2006-09-27  5:13 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     ` Eric W. Biederman [this message]
2006-09-27  5:44       ` 2.6.18-mm1 Aaron Durbin
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=m1ac4lriz5.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=adurbin@google.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --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