From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: 2.6.33: pci 0000:00:00.0: address space collision / spontaenous reboots
Date: Fri, 12 Mar 2010 14:59:28 -0700 [thread overview]
Message-ID: <201003121459.29793.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1003121520120.6929@p34.internal.lan>
On Friday 12 March 2010 01:32:17 pm Justin Piszcz wrote:
> >> Even with all boards removed:
> >> [ 0.133537] pci 0000:00:00.0: address space collision: [mem
> >> 0xe0000000-0xffffffff 64bit] already in use
> >>
> >> 00:00.0 Host bridge: ATI Technologies Inc RD790 Northbridge only dual slot
> >> PCI-e_GFX and HT3 K8 part
> >
> > how about current linus' tree with pci=nocrs or pci=use_crs?
>
> Hi, I saw your second e-mail, so it sounds like a bad board or something
> that Linux does not have a quirk for yet, but in any case, per your
> recommendations:
>
> pci=nocrs:
> http://home.comcast.net/~jpiszcz/20100312/dmesg-pci-nocrs.txt
>
> pci=use_crs:
> http://home.comcast.net/~jpiszcz/20100312/dmesg-use-crs.txt
>
> No collision when pci=use_crs is used, BUT the system still crashes.
>
> Instead of collision, it says this:
>
> [ 0.133598] PCI: pci_cache_line_size set to 64 bytes
> [ 0.133603] pci 0000:00:00.0: BAR 3: reserving [mem 0xe0000000-0xffffffff flags 0x120204] (d=0, p=0)
> [ 0.133606] pci 0000:00:00.0: no compatible bridge window for [mem 0xe0000000-0xffffffff 64bit]
> [ 0.133610] pci 0000:00:00.0: can't reserve [mem 0xe0000000-0xffffffff 64bit]
> [ 0.133617] pci 0000:00:11.0: BAR 0: reserving [io 0xff00-0xff07 flags 0x20101] (d=0, p=0)
>
> [ 0.133735] Expanded resource reserved due to conflict with PCI Bus 0000:00
Let's look at some of these messages:
pci_root PNP0A03:00: host bridge window [mem 0x40000000-0xfed0ffff]
That looks normal to me. If you could boot a current upstream kernel,
e.g., 2.6.34-rc1, I think it might print more information about your
AMD PCI address space routing. BTW, it looks like you have four CPUs,
but your kernel is only compiled to support two.
pci 0000:00:00.0: reg 1c: [mem 0xe0000000-0xffffffff 64bit]
pci 0000:00:00.0: no compatible bridge window for [mem 0xe0000000-0xffffffff 64bit]
pci 0000:00:00.0: can't reserve [mem 0xe0000000-0xffffffff 64bit]
These are just telling us that the device BAR 0xe0000000-0xffffffff
doesn't fit inside the bridge window of 0x40000000-0xfed0ffff. I don't
know why the device has that weird-looking BAR, but that by itself
shouldn't be fatal because we don't have any drivers that try to use
that BAR.
Expanded resource reserved due to conflict with PCI Bus 0000:00
This comes from e820_reserve_resources_late(). I wish it were a
more useful message and showed the actual conflict and what was
expanded, but I don't think it's a problem in itself.
pnp 00:0a: disabling [mem 0x000f0000-0x000f3fff] because it overlaps 0000:00:00.0 BAR 3 [mem 0x00000000-0x1fffffff 64bit]
We failed to reserve the 0xe0000000-0xffffffff region above, so we just
cleared out the resource. It keeps the same size, so it ends up at
0x00000000-0x1fffffff, where it appears to conflict with a lot of PNP
devices. But this isn't a real conflict; it's just Linux being stupid
because we don't handle that PCI resource correctly.
So the messages *look* alarming, but I don't see anything there that
should cause a spontaneous reboot.
Is this a regression? Did the system ever work reliably with any
Linux kernel? If not, I'd suspect a hardware problem like bad memory.
Bjorn
next prev parent reply other threads:[~2010-03-12 21:59 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-12 10:25 Justin Piszcz
2010-03-12 10:49 ` Justin Piszcz
2010-03-12 10:57 ` Justin Piszcz
2010-03-12 12:44 ` Justin Piszcz
2010-03-12 12:56 ` Justin Piszcz
2010-03-12 13:10 ` 2.6.33: pci 0000:00:00.0: address space collision / spontaenous reboots [full dmesg] Justin Piszcz
2010-03-12 20:01 ` Yinghai Lu
2010-03-12 20:02 ` Justin Piszcz
2010-03-12 20:27 ` Yinghai Lu
2010-03-12 20:34 ` Justin Piszcz
2010-03-12 20:39 ` Justin Piszcz
2010-03-12 21:30 ` 2.6.34-rc1: pci 0000:00:00.0: address space collision / spontaenous reboots [now 2.6.34-rc1] Justin Piszcz
2010-03-12 21:43 ` Yinghai Lu
2010-03-12 21:48 ` Justin Piszcz
2010-03-12 21:50 ` Yinghai Lu
2010-03-12 21:52 ` Justin Piszcz
2010-03-12 21:52 ` Yinghai Lu
2010-03-13 9:01 ` Justin Piszcz
2010-03-18 22:58 ` Bjorn Helgaas
2010-03-18 23:00 ` Justin Piszcz
2010-03-18 23:19 ` Bjorn Helgaas
2010-03-19 9:45 ` Justin Piszcz
2010-03-12 21:43 ` 2.6.33: pci 0000:00:00.0: address space collision / spontaenous reboots [full dmesg] Yinghai Lu
2010-03-12 19:44 ` 2.6.33: pci 0000:00:00.0: address space collision / spontaenous reboots Yinghai Lu
2010-03-12 20:32 ` Justin Piszcz
2010-03-12 21:10 ` Yinghai Lu
2010-03-12 21:59 ` Bjorn Helgaas [this message]
2010-03-12 22:07 ` Justin Piszcz
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=201003121459.29793.bjorn.helgaas@hp.com \
--to=bjorn.helgaas@hp.com \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=yinghai@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®