linux-kernel - Re: How do I debug PCI resource allocation problems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 16 Nov 2007 12:07:03 +0100
From:	Rainer Koenig <Rainer.Koenig@....de>
To:	Robert Hancock <hancockr@...w.ca>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: How do I debug PCI resource allocation problems

Am Freitag, 9. November 2007 00:51  Robert Hancock wrote:
> Rainer Koenig wrote:
> >
> > Ok, short description of the problem:
> >
> > I run 64-bit Linux using 2 GB of RAM, no problem at all. Then I turn off
> > the machine, add 2 more GB so that now I have 4 GB of RAM. Turning it on
> > I see the splashscreen of the boot loader, starting the kernel turns the
> > screen black and that's it. The machine comes up, I can even ssh to it
> > over the net. That is how I obtained the following data.

Just for the minutes. Problem solved. It was caused by wrong e820 information 
from the BIOS:

> > <4> BIOS-e820: 00000000df800000 - 00000000e0100000 (reserved)

That one overlaps with e0000000-efffffff which is the resource that 
then leads to this:
> > <3>PCI: Cannot allocate resource region 2 of device 0000:00:02.0

> Looks like the BIOS reserved part of that memory range already. Question
> is why vesafb is trying to reserve that range in the first place though.

Yep. 

> > Question: Memory region 2 at 120000000? That is beyond the 4GB boundary
> > and the BIOS guys I know told me that every PCI IOMEM region should
> > reside within the first 4 GBs! When running the machine with 2 GB only
> > lspci output looks like this for the VGA device:
>
> 64-bit capable PCI devices can indeed have BARs which can be located
> above 4GB. However, I can't see why lspci is detecting that from this
> configuration space: the BAR contents for region 2 are 20000008, which
> means prefetchable memory at 0x20000000 which can be located anywhere
> within 32-bit memory space. That doesn't make any sense though, since
> that's in the middle of RAM! Quite likely this bogus resource setting of
> the graphics controller is a large part of your problem. Question is
> who's doing this..

I compiled a debug kernel with lots of verbosity about PCI. That then 
reported:
<7>  got res [120000000:12fffffff] bus [120000000:12fffffff] flags 1208 for 
BAR 2 of 0000:00:02.0
<7>PCI: moved device 0000:00:02.0 resource 2 (1208) to 20000000

I guess that explains it a bit. Looks like with the "move" also the bytes that 
lspci -xx prints out are affected. 

Anyway, after we had enough information about what range was giving us 
problems the BIOS development was able to find and fix  the bug quite 
quickly. Installed new BIOS and problem was gone. :-)

Thanks anyway for the comments. 

Regards
Rainer
-- 
Rainer Koenig, Diplom-Informatiker (FH), Augsburg, Germany
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/